Solved the problem in the blog engine (which actually was problem of too intelligent cut&paste between applications), here is the post in the correct version.
I finally had the time to take a look at Google Wave, watching the 1.20h presentation at Google I/O and giving a peek into the draft documents they released.
Well, the thing that impressed me more than anything else is not about realtime editing and sharing of documents, federation capabilities, the use of XMPP as base protocol, how easy is to extend it or embed in your applications, all things highlighted with enthusiasm by all the commenters. These are all things we already have seen implemented at the the top of well know technologies like ajax and comet, and now it rather easy to pull federated content on a single web page in realtime by exploiting XMPP and BOSH, as Collecta people is brilliantly doing, and finally the fact that the platform is reach, encompassing almost all these nice things is not that big added value.
What is really impressing me is that Wave seems to be the first working example in which web applications can be built exporting both the view and the model of the underlying data, which becomes directly accessible and processable by other applications and third party bots. The view remains the HTML loaded by the browsers, making access universal, and the model is a collection of XML documents (called wavelets) to which all transformations are applied, and which are the pieces of information which are exchanged between different Wave servers or different implementations.
The side effect of this, and what Google is – I think – intentionally not shouting out loud, is that all the realtime content of the web magically becomes indexable, and a possible Google bot could start harvesting wavelets building an index of that. In practice I see that as a move for contrasting all the web 2.0 companies like Facebook which are publishing a lot of realtime content which is accessible only via personalized views, with structure hidden inside the presentation and virtually not indexable but by the data provider itself. The actual harvesting infrastructure in fact is still targeted towards static pages with a common “public” view. We have already seen how it poorly deals with duplicated content in few cases.
Take for example web archives of mailing lists: many times there are quite few different archives of the same mailing list, with different browsing interfaces. These are simple different views of the same content: harvesting all them is inefficient and search results poor, since users get many duplicated documents. The reason is that we never get directly to the data and its structure, but we always access it through views. A Wawe based approach is completely different: the mailing list “object” can export its model (the mail content and the structure of threads) by wavelets, making it possible to do both things at the best: building personalized and competing views and exporting data for indexing and integration with third party tools.
Another example is what I call the comment hell which is happening in all the microblogging and live feed platforms around the web. I've a blog (a personal one) which is mainly read by friends inside Facebook and commented both on the blog and on Facebook, making many discussion fragmented or overlapped. The reason is that Facebook (and the same would be for Twitter, Identi.ca or others) access the blog data through a particular view, atom feeds, instead of having direct access to the model; comments instead are made on the private views of the blog and Facebook, and their data model is completely separated, without any chance of interoperability. A Wave approach instead would export the model of both posts and comments, with an API for synchronizing them and update all comments in realtime between the consumers. The data of an object is therefore completely stored in the server of the original provider and it is continuously updated there, making much easier any kind of integration with third parties and bots.
I think it is too early to say if Google will succeed in this effort, since it requires to completely rethink the web and the involvement of too many people (that's the reason - I think – they are opening both the platforms and the protocol, because Wave doesn't appear lightweight and thinking to run all the software on their servers, as is Facebook is doing, is simply crazy). However I'm quite enthusiast, since it is the first time I see something that remembers the principle of Semantic Web (making data structured and interoperable) and that may work outside academic papers. Finally discovering that under the hood there is a big deal of XMPP and Pubsub technologies is a plus that makes me even happier ;)
Zlib compression can reach very high compression rates with XMPP (up to 90%), however starting a session with a mobile client can be still expensive. The best solution would be less greediness of carriers, but I'm not dealing with science fiction, so I prefer to reduce data ;) These are the rough figures about a login with my roster (~250 contacts, with ~60-70 online) and with compression enabled using Lampiro:
Can we do better? There is a new proposal, Stanza Interception and Filtering Technology (SIFT ), which may help a little by filtering incoming stanzas and allowing session "hush". Which is the importance of hush, besides not receiving unecessary presence updates? As Dave Cridland pointed out in a private chat it can improve Zlib compression by stuffing more data during hush and delaying flushes. The question was: how relevant is this action? So I did few experiments with a log of a login of mines and these are the results:
Almost 1/3 of bandwidth gained, SIFT is definitely good!
Today I had an "interesting" exchange of point of views with some people working at a large mobile operator, and the result has been enlightening. Their business model is still the same model that didn't work in the nineties for close portals like MSN or AOL, thinking to owe both the Internet and users, and they don't really get that:
We are pleased to announce the first release of Lampiro in 2009! If you are impatient just go to google code and grab it (or to the official site for directly downloading to your mobile).
These are the news:
What we think is really nice is how we now handle multiple subscription requests, which is an annoying behaviour in most clients when subscribing to IM gateways (we know that other IM networks suck, but incredibly most people still prefer MSN 
and in some way we must cope with that!).
Usually you get overwhelmed with tens of popups asking for authorizing all the new contacts, which is not the best approach for users migrating from other networks and importing their old contacts. In order to avoid this we have designed a new screen allowing handling multiple requests with few clicks (below there is a screenshot:)
Fabio Forno
