Sadly the SDL Tridion MVP retreat is over and we are on our way home after 3 great days and a surprising amount (given the great food, fine port and majestic beach) of talk about the SDL Tridion Community. Thank you SDL Tridion, and especially Nuno for making it happen.

Our goal was to focus on social media based community extensions. The building block exchange (BBX) hosted on SDL Tridion World contains several extensions, most of which have been designed and built by individuals. I am guessing that these individuals had a need for some functionality on their own projects, and tried to make it generic, and have since decided to share it in the community. I salute those of you who have done this, but it got me wondering if these extensions would be built the same way had the developers had a whole group of people helping with the solution.

I ask this because I had a great experience this afternoon whilst waiting for our taxi to Lisbon airport. I had spent the morning working on an idea we had on Friday for an ‘Upload to YouTube’ extension for SDL Tridion 2011. Now I got pretty far with my concept and I was feeling pretty proud of my solution, but I thought I would share my thoughts with the other MVPs, and to my disappointment none of them said “That sounds fine, when will it be ready”,  instead a passionate design session sparked up in the lobby of our hotel. The team came up with all sorts of other approaches, and ideas for how we could make the same set of functionality work in a cleaner, purer, and  more efficient way. There was talk of the new Custom Storage Layers offered by Tridion 2011 and Custom Deployers, Custom Transport Senders, File System Watcher Services, Custom Queue Consumers and the like.

Unfortunately, given the time and lack of whiteboard in the lobby, we failed to come up with a final design. However we thought it would be an interesting experiment to see if we could initiate a project where the SDL Tridion community actually designed (and ideally built) an extension through a crowd sourcing based collaborative approach. So here I will outline a set of functional requirements for the extension, some thoughts I had when attempting to design the extension, and an outline of my initial idea (which for the record I don’t think I like anymore).

The Use Case

From inside the SDL Tridion 2011 CME, it should be possible to upload a multimedia component which contains a video file (which must not be more than 1gb or over 10 minutes long to meet the YouTube imposed guidelines) in a supported YouTube format to YouTube. Once published, it should not be possible to delete the multimedia component from the CMS without first removing it from YouTube. It should also be possible to access the uploaded URL of the video using standard Tridion APIs and methods such as templates for publishing web content, outbound email newsletters and print publications etc, so that developers can create links to the videos and embed them in their web pages. The extension should be easy to understand and implement by an average Tridion developer.

The upload process should use credentials and channel information stored at a Tridion Publication level, although kudos will be awarded to anyone who can create a design that can use a YouTube account and channel specified by the user initiating the upload.

Based on this extension, it should be possible for a member of the SDL Tridion community to easily modify the extension so that it could be used to upload images to a site like Flickr in a similar way.

Initial thoughts

• Videos could be large, and take a long time to upload
• It probably makes sense to have the upload process use some kind of background asynchronous process to do the uploading instead of requiring the user to wait for the video to upload
• It might make sense to use the existing publishing/distribution mechanisms offered by SDL Tridion 2011 as it can mark items as published and utilize the existing templating techniques etc.
• It would be possible to make a custom deployer extension using Java which would take the file and upload it, but I didn’t like the requirement to have an SDL Tridion Presentation Server involved. Furthermore, I haven’t had many positive experiences of Custom Deployer Extensions, and I can’t think of a way to easily send feedback of the YouTube URL to the CMS. Can anyone convince me a Custom Deployer is the right way to go? Should you run the Deployer with a Custom Deployer Module on the CMS server, and use it to upload the video and utilize the Core Service to update the CMS with YouTube URLS etc? Alternatively if the Deployer is on the CD side, is there a way that a Custom Deployer Module can send information about the successful upload URL back to the CMS so that it can be saved on a Component using the OnComponentSetPublishedToPost trigger in the Event System.
• A Custom Transport Protocol with a YouTube enabled Sender and Poller could be created, but I have not done this in about 5 years, and I think you need to do it with Java (Has this changed in Tridion 2011). Is it reasonable to expect an average Tridion CM Developer to use Java in addition to the JavaScript needed for the GUI extension and the  template language(s) required to extract the video and it’s metadata from the CMS?
• It would be really cool to add a tab to multimedia components that have been published to YouTube which shows the number of plays and other pertinent information about the usage of the video.

The Initial UrbanCherry Design

1. Create a Publishing Target called ‘YouTube’ with a local file system destination of d:\YouTube (Note that a Publication Target Type is not needed which keeps the target hidden from the CME users, and prevents users trying to publish to it by mistake. I didn’t actually know this worked until today, but according to Dominic Cronin this was carried over for backward compatibility from R4 when we didn’t have Publication Target Types).
2. Create a dynamic Component Template which publishes the video, the necessary metadata values and credentials required by YouTube.
3. Create ribbon bar and context menu items called ‘Upload to YouTube’ based on the MVP HelloWorld extension sample posted by Julian Wraith.
4. Implement isAvailabe() and isEnabled() functions to only show the buttons and menu items when a multimedia component containing suitable video mime types are selected. (It would be cool if this supported multi select also). Jeremy Grand Scrutton made some samples this week which pretty much do this, and I hope he will post these sample soon.
5. Implement the _execute() function so that when the context menu or ribbon bar button is pressed, a popup appears allowing a user to confirm they want to upload the video to YouTube.
6. After confirming, a script (either JS or ASP.NET to be decided) adds the component to the publishing queue for the YouTube Publication Target.
7. The existing Publisher Service then publishes the Dynamic Component Presentation(s) to the local file system.
8. A custom windows service running on the CMS server polls the new target location, unzips the packages and uploads the video and metadata to YouTube. Once a URL is returned by YouTube it adds the URL to the metadata of the published component (using either TOM or the new Core Service) and creates a ‘success’ receipt (like the deployer does) which it stores in the d:\YouTube folder.
9. The Poller created by the standard out-of-the-box Transport Service then collects the receipt, updates the Publishing Queue for the publication transaction (to failed or success) and sets the video component as published in the CME.

Possible concerns about the initial approach

• Not really nice to have to build a custom service for each extension which uses such an approach.
• The windows service duplicates a lot of things that the Deployer already does (Like unpacking the Publication Transaction, and creating the success or failure receipts.
• The Multimedia Schema needs a field to store the YouTube URL in, which means modifying the content model in order to use the extension.
• If there are other Dynamic Component Templates linked to the Schema that the video is based on, multiple Dynamic Component Presentations will be published to the target for no reason.
• If there are multiple publishing servers, the custom windows service would most likely need to be installed on each publisher.
• Some people may consider this a hack, and that makes me a bit sad… so I want to make it better.

The first community designed community extension

I invite you all to share your ideas on what might be missing from the use case. Share your ideas in the community on how you would tackle this project. Pick holes in my design, and tell me what is wrong with it and how you would improve it. Discuss it with your colleagues, and get their ideas, and get them to share them on their own or company blogs. Hopefully we can come up with a really cool design approach, and maybe then we can start building the first real community built community extension for the SDL Tridion Community.

If you are anything like the 7 MVPs who were at the retreat this week, you might just have some fun doing it and learn something in the process. I am also pretty sure, that anyone getting involved with such a public challenge is likely to improve their chances of gaining a SDL Tridion MVP nomination for 2011 (Send an email with your nominations to sdl.tridion.mvp@sdl.com  before the end of October to make your nomination, stating why that person is a valuable member of the SDL Tridion community, more info is at http://www.sdltridionworld.com/community/mvp_award/index.aspx).