Cross-domain scripting solutions?

Topics: User Forum
Aug 24, 2006 at 4:00 PM
I'm working on building an LMS and I've been looking at the Basic Web Player sample. I was wondering what views people have on the various approaches for working around the cross-domain scripting issue outlined by ADL? (http://www.adlnet.gov/downloads/210.cfm)

I'm tending towards the SCO-fetcher idea as I have an number of potential sources of SCOs and want a solution that doesn't require constant maintenance as new sources become apparent. I'm planning to try adding to the basic web player solution as a proof-of-concept - unless anyone's already had a go already? I'd be very interested to hear of your experiences...

Thanks,
Matt.
Aug 25, 2006 at 5:40 PM
One way around this is to deploy a remote JavaScript player onto the content server and use Web Services to communicate with the Server components. This is an eventual plan for the DotNetSCORM project which already uses Web Services for LMS to API communication.

The player components can just provide the RTE and API functionality and know or find where the launching LMS is that they need to interact with. This would mean that the JavaScript on the remote system is a couple of hundred KB and can support all the remote content on that server.

Kent
Coordinator
Sep 20, 2006 at 6:51 PM
I'm thinking of going down this route too Kent. Have you looked at implementing your web services interfaces on SLK? I was noticing that there's already a pretty decent server side object model in the SDK documentation that should make implementing this pretty simple. Once we've moved up to WSS 3.0 Beta 2 Technical Refresh (which includes .NET 3.0 RC) we should be able to use Windows Communications Foundation to make the web services.