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
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?
We made a doc mistake here - try going to the SWC in the library path, then expand cocomo.swc, and select "Source Attachment", and hit edit - you should be able to add source there and not hit the issues you're speaking of.
As for screensharing + recording - I thought "watered down version of Connect" was a bit misleading : Cocomo isn't a tool for Web Conferencing. Customers who are using Cocomo are adding real-time features to their own apps, not trying to build yet another Connect Pro.
But anyhow, as has been explained, since screensharing isn't in the Flash player or AIR, it's hard for us to do - lobby your local Flash/AIR representative =). As for recording, this is definitely something we're looking at very seriously.
Since we're on the subject of recordings - how would you expect this to work? We can catch your A/V and data streams, and allow you to play them back in the context of your app (or another app you build for playback). The other trick here - who hosts the recorded data? I'd like to hear your thoughts.
thanks!
http://www.adobe.com/cfusion/webforums/forum/categ...
A little easier to get answers by going to the source, rather than standing on the corner waiting for us to come to you =).
I'll amend my project accordingly. I thought there would be a way to do this, gotta read up on that option.
As far as the positioning of Cocomo goes: sorry but have you all been given the message of 'tell customers that Cocomo is not Connect Pro and discourage use of it as such'? Because one of the clients I mentioned told me that exact same line and he was given it by someone at Adobe.
We both had to smile since we both agreed that that's exactly what people will build (amongst other stuff of course). After all it runs on the Connect back-end, it looks like Connect (a bit at least) from the front, heck it must be Connect, except I can now customize it myself and have more control over the whole app.
Of course I know Cocomo is more than that, and there's a lot more depth to it than meets the eye but I cannot see Adobe successfully discouraging developers to build Connect clones with Cocomo, and I actually think that that's the first thing on most people's mind when they see the components - they've seen them before in Connect.
You must be getting tired of me ranting about this stuff, trust me I really want Cocomo to be a huge success. But the positioning still seems a bit off to me. I'm keen to hear the pricing strategy also because if Cocomo turns out to be a lot cheaper in comparison then you may shoot yourself in the foot.
If it's too expensive then the vision for RTC apps being built on a broad scale won't happen either (I hear it every week, potential clients ask me if whatever FMS app runs on Red5 since that's what they like to use).
I wish I had an easy answer here. No doubt that the technology side of things is a given by now and you and your team have done a great job. It's the rest that needs figuring out.
Recording: I'd expect this to work like - wait for it - Connect as far as the experience goes. Play a meeting like you play a video basically. I'd imagine Adobe hosts the file(s) and there's an API we can use to request playback, or maybe even pull a file down to shift it onto our own servers. This would be charged based on bandwidth, and should be in line with S3 pricing.
Last thing: can we use stuff like PPT to SWF conversion services with Cocomo? It's another big feature that's needed or otherwise eLearning apps are a tough one. There is currently no cheap and reliable technology available to do PPT/PDF to SWF. I've researched it extensively...
I think the answer to why Adobe people are telling you the same thing is because... it's true? I certainly wasn't given the message to say it (I kinda conceived of the service, and certainly not as Connect Pro).
As for Connect clones, we shall see - it still does depend on screensharing, which would need to be in AIR/Flash. It wouldn't bother me personally to have them build Connect clones if that were to happen. I'm just guessing, but chances are that the prices charged for Connect would undercut what a developer would need to charge to build a commercial competitor with Cocomo - not because Cocomo would be expensive; rather that because Connect would likely get a sweetheart deal.
Anyhow, I'd be curious to hear more of your opinions about positioning - what parts are off, other than the "connect competitor"? I don't think either of us believes that Web Conferencing applications are the only kind of RTC apps possible?
Regarding pricing - I agree, it's a fine line. The general guideline here is that we want it to be a cheaper TCO than building your own framework / infrastructure from scratch, but generate enough revenue to make a profit over and above our own expenses. I think there's a margin worth exploring between these two.
Thanks for the thoughts re: recording. We're on the same page here, I think.
cheers
I can only agree with Stefan that the screen-sharing feature is indeed what we need. I'm thinking of building a virtual classroom application but it's not an option without screen sharing. Saying that it's technically impossible is of course not true - why can't we use the plug-in like Adobe does? The problem of using Connect for the virtual classroom project is pricing. Feel free to check out what the cost would be of 1 hour with 1 teacher and 50 students??? This kind of pricing makes it impossible to build a profitable business :(
Tom
Why does the pricing for adobe connect seem substantially more than other options like Gotomeeting, dimdim etc which offer similar service ?