Confirmed users
70
edits
Education/Projects/JetpackForLearning/Profiles/MUPPLE: Difference between revisions
Jump to navigation
Jump to search
Education/Projects/JetpackForLearning/Profiles/MUPPLE (view source)
Revision as of 01:29, 1 February 2010
, 1 February 2010→Technical Notes & Further Work
| Line 118: | Line 118: | ||
=Technical Notes & Further Work= | =Technical Notes & Further Work= | ||
The current [[http://github.com/Laurian/MUPPLE | The current [[http://github.com/Laurian/MUPPLE prototype code]] is quite hard to follow, it has grown organically around various real and supposed limitations of Jetpack. | ||
We adapted some cross-site scripting style strategies in order to achieve a tight coordination between Jetpack and the code in the slidebar; therefore we use a hidden iframe (fed with data URIs) to communicate from the slidebat to jetpack (which listens for the load event), while from jetpack to slidebar or to any tab we inject script tags with raw code or JSONP. | We adapted some cross-site scripting style strategies in order to achieve a tight coordination between Jetpack and the code in the slidebar; therefore we use a hidden iframe (fed with data URIs) to communicate from the slidebat to jetpack (which listens for the load event), while from jetpack to slidebar or to any tab we inject script tags with raw code or JSONP. | ||
We use the Jetpack storage in a particular way: we store a large part of the slidebar's DOM tree into the store instead of individual objects. The concept is that the slidebar it is not a mere View (as in MVC) of a Model, but the Model itself, directly manipulable. If someone drags and reorder some actions (DOM elements) there is no need for propagating those changes to an underlying granular database, no need to determine which individual records have to be updated in a consistent manner. This approach was inspired by the [[http://en.wikipedia.org/wiki/Naked_objects | We use the Jetpack storage in a particular way: we store a large part of the slidebar's DOM tree into the store instead of individual objects. The concept is that the slidebar it is not a mere View (as in MVC) of a Model, but the Model itself, directly manipulable. If someone drags and reorder some actions (DOM elements) there is no need for propagating those changes to an underlying granular database, no need to determine which individual records have to be updated in a consistent manner. This approach was inspired by the [[http://en.wikipedia.org/wiki/Naked_objects Naked Objects pattern]]. | ||
Since the slidebar is also the Model, we need to store things there which should not be revealed to the user (such as IDs, URIs, types). For this prototype we chose to use RDFa annotations. We will investigate if HTML5 microdata would bring us more benefits; we're also thinking of the possibility of creating a workflow microformat. | Since the slidebar is also the Model, we need to store things there which should not be revealed to the user (such as IDs, URIs, types). For this prototype we chose to use RDFa annotations. We will investigate if HTML5 microdata would bring us more benefits; we're also thinking of the possibility of creating a workflow microformat. | ||
Having such a Model+View combo would allow for a very simple sharing strategy: you could just select and copy a workflow from the slidebar, and paste it in a blog post---all the underlying data would be just propagated and MUPPLE could just recognise in any web page | Having such a Model+View combo would allow for a very simple sharing strategy: you could just select and copy a workflow from the slidebar, and paste it in a blog post---all the underlying data would be just propagated and MUPPLE could just recognise in any web page published workflows and prompt the user to import them at will. | ||
Having RDFa annotations also allows us to serialise the Model to RDF and it would be possible to publish a workflow via a public RDF store (like the [[http://www.talis.com/platform/ | Having RDFa annotations also allows us to serialise the Model to RDF and it would be possible to publish a workflow via a public RDF store (like the [[http://www.talis.com/platform/ Talis Platform]]), this would allow MUPPLE to look-up existing workflows involving a site the user is browsing. And what we believe that is more important in collaboration: it may allow an user to discover friends and co-workers workflows---this would be achievable by publishing workflows with a [[http://xmlns.com/foaf/spec/#term_maker foaf:maker]] relation, and the user's foaf profile could point to friends, organisations (hence co-workers). If the user lacks an explicit foaf profile, we could use one based on his Twitter relations: http://semantictweet.com/ | ||
We consider each recordable action as an annotation, | We consider each recordable action as an annotation, and we would like to have them compatible/interoperable at some level with [[http://www.openannotation.org/ Open Annotation]] initiative. We already use [[http://xpointerlib.mozdev.org/ xpointerlib]] for 'note actions' which would allow us to create [[http://www.w3.org/2001/Annotea/ Annotea-like]] annotations and be interoperable with Open Annotation. | ||
Xpointerlib proved quite useful in prototyping Ubiquity commands recording and sharing, having them as recordable actions in MUPPLE could enable the creation of workflows based on an 'open market' of Ubiquity commands and provide by this a straight forward way in extending MUPPLE functionality. Moreover, think of the possibilities that the command translate from Ubiquity could bring to MUPPLE: collaboration that spans language barriers. | |||
=Original Proposal= | =Original Proposal= | ||
The initial [[vision MUPPLE II|vision of the MUPPLE II]] Firefox Jetpack talks more about the motivation and introduces a use case to write collaboratively a paper using Web 2.0 webpages. | The initial [[vision MUPPLE II|vision of the MUPPLE II]] Firefox Jetpack talks more about the motivation and introduces a use case to write collaboratively a paper using Web 2.0 webpages. | ||