LiveCycle Collaboration Service Gets a New Lease Of Life

Adobe's LiveCycle Collaboration Service has been rescued and given a new lease of life by Influxis. Now called the Influxis Collaboration Service (ICS) it gives existing LCCS customers the chance to migrate their applications over to ICS. If you recall, Adobe previously announced that they would shut down and discontinue the LCCS service without any obvious ways for existing customers to keep their LCCS based products and services online - ICS is therefore good news for many of those customers.

ICS will be comprised of two different account types, dedicated and shared accounts, with various price points starting at $25/month for a 10connection shared account. An extensive FAQ can be found on the Influxis site.

As you may know, LCCS (or now ICS) enables you to build real-time collaborative applications quickly using a variety of pre-built modules including FileShare, Chat, Whiteboard, Webcam and of course - dare I mention it - screensharing.

Let me know if you're building any applications with ICS and I'll link to them here.


Adobe To Shut Down LCCS, Customers Badly Affected

After several recent announcement around Adobe's LiveCycle platform, it may not come as a surprise to some that the LiveCycle Collaboration Service (formerly Cocomo, formerly Flash Collaboration Service) will be shut down at the end of 2012. What may be a surprise however is the relatively short notice that Adobe is giving existing customers and a total lack of a migration path, leaving many people in a real tight spot.

Remember that LCCS is a hosted collaboration service, effectively cloud based, that allows developers to build real-time communications right into their Flex applications. The work that has gone into LCCS is impressive, and the platform offers a range of great features such as room provisioning APIs, live and audio and video communications (both over RTMFP and RTMP) and even screensharing capabilites (but let's not warm that topic up again...).

› Read Full Article


Stratus 2 Released, Takes Peer to Peer in Flash to New Levels

Adobe have just announced the immediate availability of the version 2 of Stratus, an update to the existing Peer 2 Peer rendezvous service that was launched in 2008.

In Adobe's words: "Adobe Stratus 2 enables peer assisted networking using the Real Time Media Flow Protocol (RTMFP) within the Adobe Flash Platform. The most important features of RTMFP include low latency, end-to-end peering capability, security and scalability. These properties make RTMFP especially well suited for developing real-time collaboration applications by not only providing superior user experience but also reducing cost for operators."

While this sounds like the same capabilities that the previous version of Stratus offered it contains some significant updates, the main one being support for RTMFP Groups.

› Read Full Article


Making Sense of Stratus, LCCS and FMS

There has been a bit of confusion around which one of Adobe's collaborative platforms offers or will offer certain features. In particular many people have asked if a developer always needs to rely on a hosted service such as Stratus or Lifecycle Collaboration Service (aka AFCS aka Cocomo) when wanting to use the new RTMFP protocol which will deliver (partly is delivering already) new and exciting features to the Flash Player.

To clear thing up, Kevin Towes, FMS Product Manager at Adobe, just posted the following information to the FlashMedia List:

STRATUS - this will always be ahead of the curve, providing a way to help us roll out new features that are in Flash player, before we can have a server offering. The service is and will remain as a free non-commercial service from Adobe. This service is not FMS, and has no ability for Server side scripting, or customization.

AFCS/LIVECYCLE COLLABORATION SERVICE - this will be a commercial option for customers interested in building a business that includes RTMFP. We introduced a pricing model, and it has support for the features found inside Stratus 1.0 (supporting Flash player 10.0). Key advantage with this service is the framework, which is an option for developers to get started, and leverage RTMFP to RTMP failover technology. You still will not have access to server side scripting, but there are lots of APIs in the framework to get you going. The goal for this service is to provide developers an option to bring this technology into your solution.

FLASH MEDIA SERVER - we have not announced any new version of FMS yet that will support RTMFP. We did hint yesterday that we'll be updating FMS3.5 to version 3.5.3 later this year to support the new FP 10.1 features - and in a future version after that release - FMS may be one of your options to host a local service to build your own P2P applications - including introductions, and supporting server side programming.

Thanks Kevin, I think this clears things up somewhat.


Making Sense of Stratus, LCCS and FMS

There has been a bit of confusion around which one of Adobe's collaborative platforms offers or will offer certain features. In particular many people have asked if a developer always needs to rely on a hosted service such as Stratus or Lifecycle Collaboration Service (aka AFCS aka Cocomo) when wanting to use the new RTMFP protocol which will deliver (partly is delivering already) new and exciting features to the Flash Player.

To clear thing up, Kevin Towes, FMS Product Manager at Adobe, just posted the following information to the FlashMedia List:

STRATUS - this will always be ahead of the curve, providing a way to help us roll out new features that are in Flash player, before we can have a server offering. The service is and will remain as a free non-commercial service from Adobe. This service is not FMS, and has no ability for Server side scripting, or customization.

AFCS/LIVECYCLE COLLABORATION SERVICE - this will be a commercial option for customers interested in building a business that includes RTMFP. We introduced a pricing model, and it has support for the features found inside Stratus 1.0 (supporting Flash player 10.0). Key advantage with this service is the framework, which is an option for developers to get started, and leverage RTMFP to RTMP failover technology. You still will not have access to server side scripting, but there are lots of APIs in the framework to get you going. The goal for this service is to provide developers an option to bring this technology into your solution.

FLASH MEDIA SERVER - we have not announced any new version of FMS yet that will support RTMFP. We did hint yesterday that we'll be updating FMS3.5 to version 3.5.3 later this year to support the new FP 10.1 features - and in a future version after that release - FMS may be one of your options to host a local service to build your own P2P applications - including introductions, and supporting server side programming.

Thanks Kevin, I think this clears things up somewhat.


Behind-the-Scenes Peak at ConnectNow and AFCS Architecture

InfoQ has an interesting article about Adobe's Collaboration Platforms including ConnectNow and AFCS. In it Raffaele Sena who is a Senior Computer Scientist in Adobe's Business Productivity Unit talks about the scalability challenges of a system such as Connect and how the team has addressed them.
In particular he mentions the use of Terracotta and how it helped scale the system by providing the cluster with distributed memory that also makes failover scenarios much easier to handle. It's an interesting read.


Adobe Wants Your Feedback on AFCS Pricing

The Collaborative Methods blog has seen an update in which Varun Parmar, the AFCS Product Manager, is asking for feedback on the proposed pricing models for AFCS (aka Cocomo). For those not in the know, AFCS stands for Adobe Flash Collaboration Service, a hosted service that provides real-time capabilities to Flex and AIR based applications. It runs on the Adobe Connect backend and provides a similar feature set to Adobe's own product (similar, yes, not identical but let's not go into that now ;-)

The proposed pricing models are, as you can imagine, fairly complex since they aim to support a variety of different usage models as well as data intensive or messaging intensive applications. The proposed models will include par per use pricing as well as a zero upfront costs, both of which are plus points in my book. What remains to be seen is how the running costs of AFCS compare to something like FMS, especially for smaller apps that do not require the infinite scalability of a cloud based service.

I cannot remember a time in which Adobe would ask its customers for feedback on proposed pricing *before* the product was fully released and I would therefore urge everyone to voice their opinions on the proposed pricing models now. Note that actual figures on price points have not yet been made public, but as Varun outlines this will happen in the not too distant future.


Screensharing in AFCS (Cocomo) - Are the Foundations Being Laid?

Don't worry, this is not going to be another episode of me harping on about the need for screensharing in Flash, and AFCS in particular. But it is about a little discovery I made when working with AFCS (top secret project ;) over the last week or two.
I needed to extend the SharedWhiteBoard component and prevent it from connecting automatically when it was added to the display list. That turned out to be pretty easy, and whilst scrolling through the list of AFCS classes in Eclipse to pick out SharedWhiteBoard I found this:

There are several classes which, judging by their names, have some role to play during a screen share session.
Unfortunately the sources for those classes are not included with the AFCS SDK, instead these are baked into the SWC. The source code that is available however also makes a few loose references to screensharing, and the grouping and managing of screenshare-originated streams.

So who knows, maybe the foundations for screensharing are being laid. One can hope.


Bye Bye Cocomo, Hello Flash Collaboration Service

The wait is over: Adobe have just announced the official name for what was the service code named Cocomo. The official name is now Adobe Flash Collaboration Service (which in short would make it AFCS, or even shorter FCS - ring any bells? :).

Adobe describes AFCS as follows: "Adobe Flash Collaboration Service is a Platform as a Service that allows Flex developers to easily add real-time social capabilities into their RIA (Rich Internet Applications). Comprised of both Flex-based client components and a hosted services infrastructure, Adobe Flash Collaboration Service allows you to build real-time, multi-user applications with Flex in less time than ever before. And because Acrobat.com hosts the service, issues like deployment, maintenance, and scalability are taken care of for you."

I personally love real-time capabilities in web apps and AFCS (just like FMS) really excites me. I have a long list of ideas that I'd love to build with it. What's tricky right now is picking the right tool for the job. My current tool of choice is FMS and has 90% of the features I need in a real-time enabled web app. The developer workflow may not be best with FMS still stuck at AS1 on the server side and very limited APIs for the outside world to talk to it, but most of the time I can build what I want with it.

› Read Full Article


Using RTMFP with Cocomo

Nigel Pegg recently posted about how to use RTMFP in Cocomo. I really want to get more to grips with Cocomo so I spent the morning setting up the provided examples and generally reading up on the docs. Cocomo is a very exciting technology, but I think Adobe *must* add both screensharing as well as recording capabilities to the platform. Without both of those features it will seem like a watered down version of Connect, and not something that's on par.

Actually this reminds me - I've had two separate clients ask me about the relationship between Connect Pro, Acrobat Connect Now and Cocomo. While I know what Cocomo is and does I never thought about Connect Pro and Acrobat Connect Now. In fact I didn't even know they were two separate products or services... What both clients told me was that they really like the Connect Now UI (I think this is what previously code named Brio) but did not like the more expensive Connect Pro so much. However paying extra to lift the limit on Connect Now does not seem to be possible. Very weird, and a slightly fragmented setup. Adobe is missing a trick here since users are not getting what they want. Maybe connect Pro will be updated to have the Connect Now UI sometime soon? If not then Cocomo may be your best bet - roll your own look and feel - but of course we need those aforementioned features...

Sorry I got sidetracked there... the reason for this blog post is a different one. While I was playing with the Cocomo SDK I followed the instructions to set up Flex Builder (FB). I added the Flash Player 10 Cocomo SWC to my library path and also added the source code to the source path, according to the Cocomo docs:
Setting the source path for debugging
If you'd like to use Cocomo's supplied source code to help with debugging:
1. Choose the Source path tab.
2. Choose Add Folder...
3. Navigate to /src/.
4. Choose OK.

If after that you try and use the protocol property on the AdobeHSAuthenticator class however FB will complain about that property not being present on AdobeHSAuthenticator. I figured that FB was likely looking at the source rather than the SWC, so I removed the sources again from my project. Bingo, that worked and FB stopped complaining, my project compiled and I can now use RTMFP in my Cocomo rooms.
I figured I'd post this here to help others but also ask: is it possible to have both the sources and the SWC added to FB to aid with debugging, but have FB pick the 'right' code, in this case the SWC?


More Entries