TELS (Pas Learner Runtime, Authoring Runtime, etc... )
[PAS Portal Repostory]
(CoLab solo version doesn't have any user management. It has a fake login screen. COUld replace this:
- User logs in, selects from configuration files available for Co-lab. Then Co-Lab would then load the configuration file (done within a new architecture for loading and storing data. Then co-Lab would start up and store data.
- from Stephen B: can we support open ID in a shared credentialing system? - could allow the integraiton of separate authoring frameworks
- from Jakob and Tony: How can we add a new technology to the SAIL portal, using the SDS? Is it hard?
- Stephen: actually, this is what we're doing for O-Trunk
- Jakob asks about data formats. CIEL and Co-Lab has some data formats for co-lab data, as well as for models and other kinds of objects. They also have a model for metadata. We should expect some kinds of problems when CIEL is loading some data from SAIL environments, concerning the available metadata, etc.
EMF (from Scott)
using XMI as the output format for saving the user data. Our schema (rims and socks, agents and bundles) comforms to XMI.
XMI is a more specific format than plain XML. Its not a schema itself, but more specifically was designed for writing out models and the data within models. It is quite generic. It defines a few name space attributes, then a particular way of creating XML ("use this format", etc - e.g., the name of the class, the element name, the neames of the properties of the class, element and property names, type of the values of the properties).
This is generated by the EMF ___
We are parsing that data to generate reports in the SDS.
So SDS is becoming more particular to XMI, w.r.t. rims and socks.
If we wanted to store another kind of data in the SDS, then that part of the
- to store things other than our specific format of XMI (rims/socks, etc)
- or you could just use the existing XMI ("session bundle XMI format"). Build a standard XML header, all your data, and footer.
- the alternative (of generalizing the SDS) is an interesting question. By generalizing it, we may also want to take out the reporting functions. SDS is also generating a jnlp, specific, to launch the SAILl CORE EMF launcher, which then handles downloading the user data, then when you quit sending the data back to SDS.
- so Co-lab would need to add the data access and reporting features, but this would allow a more general SDS version.
- Identical tool interface
- Ideal end result: tools can run in SAIL and CO-Lab, without any changes
- Identical tool messaging
- Ideal end result: both environment have the same messaging facilities
- Collaboration between SAIL and CO-Lab users!?
- Dedicated collaboration tools!?
- Synchronisation of tools?
- Standard set of shared environment independend tools:
- Tool content editor (SAIL authoring tool)
- Standard underlying messaging framework
- Messaging (JXTAPOSE, peer to peer) JXTA
- Sharing Beans between enviroments
- Connecting those beans with bean connectors to a shared messaging framework.
- Having those beans beable to communicate and colloborate with each other via the subsystems(connectors, message frameworks,etc...)
- CO-Lab to automatically sync data in both user enviroments - messaging important.
This is a collaboration between the SAIL development team and the Co-Lab team from University of Twente, the Netherlands