February 18, 2009
Just a quick post to announce that we’ve launched a Showcase Gallery on Adobe Labs to highlight compelling applications powered by AFCS. We’re starting off with a small list [... thanks to Nisse Bryngfors, Kaushik Datta, Hog Wild Poker Leagues, and Acecis for working with us and allowing us to showcase their cool apps!] This is just the beginning and our hope is that in the coming weeks we can rapidly expand the Showcase to include other community-developed apps. If you’d like your app to be included in the AFCS Showcase then please submit it here. We’re really interested in adding apps that truly take advantage of In-Context Collaboration features provided by AFCS.
Varun
February 15, 2009
With all the hoopla last week around the name change (Cocomo->AFCS), we neglected to mention that along with the new name, we’ve pushed a new build of the SDK as well as updated the service.
Go get it here
A few words on process – Generally, this build is the result of feedback from the user forums. We take every post very seriously, and spend time considering whether and how we should update the SDK and service. The vast majority of the list below is the result of user feedback. Keep it coming!
What’s new for this release?
• A real, commercial name. Cocomo is now “Adobe Flash Collaboration Services” (AFCS).
• CustomUserField in UserManager is now fully supported.
• RoomManager has been augmented with 4 new settings :
• guestsNotAllowed: Allows OWNERs to disallow anyone not authenticated to their rooms.
• roomLocked: Allows OWNERs to prevent any further entry to a room.
• roomUserLimit: Allows OWNERs to set a user limit on their rooms.
• roomTimeOut: Allows OWNERs to set timeouts on their rooms (after which the room shuts down).
• Fixed ConnectSession.logout so that rooms can be re-logged in properly. ConnectSession.close() was added to completely clean up a session (doesn’t allow re-login).
• Fixed: Developer Quotas being exceeded was not reported in the AFCS framework (now throws SessionEvents from ConnectSession, or an RTE if it’s not being listened to).
• Management API :
• Server-side: getSessionSecret now returns the current session secret instead of creating a new one.
• Client-side: Added AccountManager.invalidateSession method to invalidate the current session secret
• UserDescriptor.RTMFP added to tell if a user has come in via RTMP.
• Fixed: P2P audio periodically dropping out.
• Fixed: P2P video freezing as it switches to hub and spoke.
• Fixed: Whiteboard not able to set backgroundColor/alpha via MXML.
• Added support for getting/setting nodeConfigurations on every collab and sharedModel component.
• New Examples:
• MultipleSessions – shows how multiple IConnectSessions can be used in one application.
• ZoomLayout – builds a custom webcam layout using WebCamSubscriber.
• PeerToPeerRtmfp – shows how to use P2P/RTMFP for A/V.
• Dev console additions to allow configuration of file and stream groups.
• Dev console additions for managing new RoomManager settings.
• Fixed: XML objects are properly serialized/deserialized went sent via MessageItems.
• Capacity and service performance improvements.
February 12, 2009
What’s in a name? When we first started, Cocomo (Common Collaboration Model) was the codename that we used internally, which also became our public identity. But, we also started to realize that it’s heavily overloaded; between the Beach Boys song, the Constructive Cost Model (COCOMO), and our personal favorite, the Cafe Cocomo — a salsa dance bar that is literally a mile from our office… it’s not a name we could really call our own.
As we get closer to offering the service commercially, we knew it was time to adopt a corporate name. We believe the Platform as a Service we’re making should be in the toolbox of any Flash/Flex developer, so we wanted “Flash” in the name. From there, it was a matter of describing what the offering is : Adobe Flash Collaboration Service.
Taking on a “real” name is the first in a series of steps toward commercial availability; there’s still lots to be done. We wanted to give a look at the AFCS roadmap for the upcoming months, with a rough chronological order:
- Proposing the pricing model we’ve been working on
Putting it out there, and taking feedback. We think we’ve got something that will work, but we want you to be the judge. We’ll be kicking off discussions around this in the next few weeks.
- Expanding the availability of early commercial adoption
We’ve been working with some “lighthouse” customers to validate the technology and the business plan. We’re going to open this up some more and let more people build commercial applications w/ AFCS, before it’s broadly available.
- Working on server-to-server management APIs
We know that developers want to be able to remote control more processes in their AFCS rooms. We’ve got some plans to allow “bots” in rooms, automate more tasks via HTTPS, and generally make it easier for developers to integrate their back-end business logic with our real-time sessions.
- Building an eCommerce infrastructure for services
How many developer services does Adobe currently sell? That’s right, none. We’re working with various teams inside Adobe to get the mechanics in place so that we can actually charge for usage of AFCS.
- Taking a serious look at recording and playback of data and A/V streams
We can’t promise that this will happen very soon, but it’s something we’re actively working on prototyping. Lots of interesting (hard) problems to solve before we can really offer this as a service.
- Continual improvements in RAS (Reliability, Availability, and Scalability)
Before we start charging, we want to keep ensuring we’ve got a rock solid backbone. So far, so good during beta, but we’re always working to make sure we can handle demand.
…all the while, we’ll continue to take feedback from our forums and add new functionality to the service. As you can imagine, schedules are notoriously hard to predict, but we’ll do our best to be open about our priorities and progress.
Thank you all for your help and continued support!
