Every now and then a new search engine comes out, and (I suspect like everyone else) the first thing I try searching for is my own name. And, woohoo, the top link using Microsoft's new bing.com is my own website. I'm only second and third in the search results on Google. I like Bing :)
Well, at least until it finds out about that much more famous pottery-painting William Billingsley and, quite rightly, dethrones me from the listings the way Google did!
Thursday, 4 June 2009
Tuesday, 2 June 2009
XML modifications in Google Wave and SCFX
So, a few of the technical bits of Google Wave remind me of some things I looked at briefly during my PhD a few years ago (but only a few, and solving a different problem -- I'm not claiming to have "invented Google wave" like those people who claim Harry Potter was really their idea).
A part of Google Wave's protocol is way of sending changes to an XML document, so that changes you make locally are reflected on the "canonical" server copy of the document and can be broadcast out to other viewers. This was something I looked at too -- albeit in a "good enough is good enough" sort of way -- so I was interested to see how the problems we faced differ, and what Google's solution looks like.
Well, Wave has to solve a few extra problems: their documents are edited by many people at once, so the change format has to be transformable, so that different people's changes can be reconciled. (In the Intelligent Book, even though pages are concurrently editable, exercises are usually worked on by students individually, so I could duck this issue.) They also have to deal with federated servers, security, etc. So, they've been looking at a much harder problem than I was with my little change format. And while their solution is still being refined, so far it looks pretty good.
However, from my very brief look, there was something that made me think "hmm, maybe you've missed a trick here". Google Wave's deltas are explicitly defined as an XML format. With SCFX (Simple Change Format for XML), which was my remote XML change API, I decided just to define function calls for each kind of modification -- including a "with" call for wrapping multiple calls into a transaction -- and to avoid defining a serialisation. In other words, I avoided specifying any particular XML schema. Why? Well, I realised that the function calls to my API were going to be made both locally and remotely. In the local case, it's inefficient to go writing and reading XML just to make a call to change a document. And in the remote case, whichever Web RPC format you use already defines a format for serialising a function call into text. If I use XML-RPC, then the XML-RPC stub itself will turn my function calls into a piece of XML to send over the Web. The same happens if I use SOAP. So, by refusing to define an XML format, I could just say "here are the functions, call them using any of the following RPC technologies". So, for instance, I could pass changes from the server back to the browser marked up as Javascript code if I liked. And I wasn't tied to this extra step of deserialising my own special XML format.
Apart from that -
A part of Google Wave's protocol is way of sending changes to an XML document, so that changes you make locally are reflected on the "canonical" server copy of the document and can be broadcast out to other viewers. This was something I looked at too -- albeit in a "good enough is good enough" sort of way -- so I was interested to see how the problems we faced differ, and what Google's solution looks like.
Well, Wave has to solve a few extra problems: their documents are edited by many people at once, so the change format has to be transformable, so that different people's changes can be reconciled. (In the Intelligent Book, even though pages are concurrently editable, exercises are usually worked on by students individually, so I could duck this issue.) They also have to deal with federated servers, security, etc. So, they've been looking at a much harder problem than I was with my little change format. And while their solution is still being refined, so far it looks pretty good.
However, from my very brief look, there was something that made me think "hmm, maybe you've missed a trick here". Google Wave's deltas are explicitly defined as an XML format. With SCFX (Simple Change Format for XML), which was my remote XML change API, I decided just to define function calls for each kind of modification -- including a "with" call for wrapping multiple calls into a transaction -- and to avoid defining a serialisation. In other words, I avoided specifying any particular XML schema. Why? Well, I realised that the function calls to my API were going to be made both locally and remotely. In the local case, it's inefficient to go writing and reading XML just to make a call to change a document. And in the remote case, whichever Web RPC format you use already defines a format for serialising a function call into text. If I use XML-RPC, then the XML-RPC stub itself will turn my function calls into a piece of XML to send over the Web. The same happens if I use SOAP. So, by refusing to define an XML format, I could just say "here are the functions, call them using any of the following RPC technologies". So, for instance, I could pass changes from the server back to the browser marked up as Javascript code if I liked. And I wasn't tied to this extra step of deserialising my own special XML format.
Apart from that -
- Wave's protocol looks like just a diff -- add and delete of content -- whereas SCFX also included larger operations such as move and copy, so that for instance an app that used a tree of complex GUI components to show a tree of XML elements could just move them rather than having to recreate them afresh if the XML element at the top was moved.
- Google Wave relies on a particular character layout of the XML -- for instance there must be no empty tags (
<foo />), and all the clients need to treat whitespace identically. SCFX used XPaths to address content, so this wasn't so fragile. (But an XPath would be difficult to transform).
Monday, 1 June 2009
"Everything's going my way"* (ramblings on Google Wave)
* The title of this post is just because I had "Oh What A Beautiful Morning" stuck in my brain at the time I wrote this!
During my PhD (2003-2007) I developed a system called "The Intelligent Book" (public demo returning soon). One aspect of it is a collaboratively edited textbook that let you embed graphical gadgets into the pages -- circuits etc -- and as students worked with them, intelligent components on the server would interact with them, add annotations, and offer their advice right back into the page. And it all used lightweight open protocols (the communication was around XML-RPC and Javascript), but allowed the graphical components to be applets because doing graphical stuff in HTML was tough back then. It even used a message format describing changes to an XML document.
In 2007, I noticed some of the movement within Sakai (an open source Courseware Management System) was towards a similar easily-edited gadget-embeddable structure. A book chapter I've written -- chapter 13 of this book -- discusses some of the economic effects that I think are pushing learning products in this direction.
Last week, Google announced Google Wave. This isn't aimed at education -- they're pitching it as a grand attempt to replace email, instant messaging, and all other forms of Web communication (good luck!). But within it, it has collaboratively edited content, with graphical gadgets that can be embedded at the client, and intelligent robots that can be embedded at the server. The communication is about changes to XML documents, and the robots mark changes back up into the original page...
Of course, there was more to the thesis of the Intelligent Book than just gadgets, robots, and editable pages -- and of course Google Wave solves many different and bigger issues than I've described here. But it's always quite reassuring to see commercial software endeavours heading in similar directions to ones I've advocated in my research, even if only in small ways and in unexpected fields. Makes me feel as if maybe I'm not just a lone nutcase baying in the wilderness after all.
During my PhD (2003-2007) I developed a system called "The Intelligent Book" (public demo returning soon). One aspect of it is a collaboratively edited textbook that let you embed graphical gadgets into the pages -- circuits etc -- and as students worked with them, intelligent components on the server would interact with them, add annotations, and offer their advice right back into the page. And it all used lightweight open protocols (the communication was around XML-RPC and Javascript), but allowed the graphical components to be applets because doing graphical stuff in HTML was tough back then. It even used a message format describing changes to an XML document.
In 2007, I noticed some of the movement within Sakai (an open source Courseware Management System) was towards a similar easily-edited gadget-embeddable structure. A book chapter I've written -- chapter 13 of this book -- discusses some of the economic effects that I think are pushing learning products in this direction.
Last week, Google announced Google Wave. This isn't aimed at education -- they're pitching it as a grand attempt to replace email, instant messaging, and all other forms of Web communication (good luck!). But within it, it has collaboratively edited content, with graphical gadgets that can be embedded at the client, and intelligent robots that can be embedded at the server. The communication is about changes to XML documents, and the robots mark changes back up into the original page...
Of course, there was more to the thesis of the Intelligent Book than just gadgets, robots, and editable pages -- and of course Google Wave solves many different and bigger issues than I've described here. But it's always quite reassuring to see commercial software endeavours heading in similar directions to ones I've advocated in my research, even if only in small ways and in unexpected fields. Makes me feel as if maybe I'm not just a lone nutcase baying in the wilderness after all.
Subscribe to:
Posts (Atom)