On Aug 19, 2005, at 5:10 PM, Aral Balkan wrote:
Correct me if I'm wrong but in the current spec, SCOs (in the example I gave, SWFs) would have to be able to communicate with the LMS directly and what we're calling the shell (which in our example looks like a bundled SCO) would also have to communicate with the LMS. All through JavaScript.
You're correct on this point. The bundled SCO must communicate with the LMS. How you accomplish that is up to you, however. If you have one or one hundred Flash pieces, they're still going to be embedded in an HTML page, which contains (or links to) JavaScript that will wrap your content with the functionality required to talk to the LMS. Now whether each Flash element you create is constructed to talk to that HTML, which relays the JavaScript, or you have one "shell" in Flash which handles the communication with its parent HTML -- that's again entirely at the discretion of the developer.
In the case of Flash, this is pretty easy to do either way with the Flash/JS Integration Kit. You can have a shell which controls the presentation of other "child" Flash elements. You can daisy chain Flash elements. You can have one giguntus Flash file that's 10,000 frames long in the timeline, with all the crappy scenes you want. As long as you can communicate with JS, you can isolate all the necessary LMS-talking functionality in JavaSCript. Or, if you know you're going to be porting only to IE on Windows, use IE.
The point is, that you don't HAVE TO have all your Flash elements talk to JS, nor do they need JS to talk to each other within the same SCO. Only the SCO must talk to the LMS via JS. How you accomplish that is completely up to you.
Now, I was thinking about an all-Flash LMS. That's not possible today because SCOs cannot communicate with Flash via JavaScript and cannot directly communicate with an application server via JavaScript.
Well, you can certainly build the interface for an LMS in Flash. But the back-end is going to require something beefier. That's not exactly a SCORM issue. It's more of the fact that Flash is a client technology, and you need a server technology to produce and LMS. Now, if you wanted a SCORM Content Package "Player" -- standalone on your desktop or on the web, and playing content packages where the content was almost entirely in Flash -- you would still need some kind of back-end technology (to unzip content packages), and it might be doggone slow (parsing XML, scraping HTML pages for the embedded .SWF files, etc) -- but it's not impossible today.
But an all-Flash LMS isn't.
I just can't help but think how cool it would have been if they had used, for example, web services instead.
At that point, you're not talking about an all-Flash LMS. You're talking about stand-alone content that, if web-accessible, could communicate with an LMS that exposed the API as a webservice. That IS something ADL is looking at, though it's not high on the priority list.
That's not to say it's not important. Most everyone in ADL believes it is. We have a gigantic list of priorities (for obvious reasons I can't list all of them). But maintaining the specification, the test- suite and the Sample Run-Time Environment, as well as producing a host of how-to content for developers is a big one.
You also have to consider that when SCORM first started in 1999, web services were in such infancy. Even today, there'd still debate as to which protocol to support: SOAP/WSDL, REST, RSS...
Understand, I'm offering a personal perspective and not speaking on behalf of ADL or CTC. I personally have little doubt that SCORM will eventually evolve to some XML format, but I also think it would take a long while for adoption, given the SCORM 1.2 is only starting to hit mainstream adoption, and that was finalized (more or less) in 2001.
Hope that clears things up for you, Aral. If not, keep asking questions, because so far they're excellent (whether I'm answering them well enough, you have to let me know).
-a- _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
