't Bijstere spoor

Firefox 2.0 is in beta, and will be finished not too long from now. It will include a lot of new features. My favorites so far are the spell-checker, the improved RSS system and Microsummaries. This article is about the latter.

Microsummaries is basically a system to update the title of bookmarks from the backend. The best example would be that if you bookmark an item from EBay and place the bookmark on the toolbar, you can see in the toolbar the current price for the item (and this will be updated every now and then). I also saw examples for FedEx, where you could check out the delivery status live, without actually opening the page.

I tried enabling this for my blog, and it was quite easy. You can check it out (in firefox2) by dragging the url from the addressbox into the bookmark toolbar, right clicking and clicking the last item in the title-dropdown field. It will show you the latest article title.

Changing the title of the bookmark (sorry for the bad color theme, not on my own computer.

This is microsummaries in action

How to implement it yourself

The easiest way to do this, would be to use a piece of text from your website (in my case the latest article title) and give it an id element. If you browse the source of this site, you will see that the top link in the article sidebar contains id="latestArticle".

The next thing you need to do, is to include it in the header of your website:

In my case the url to the microsummary can be found in /services/microsummary, but thats up to you. If you check that link out, you will find the XML that is needed to create a microsummary.

Microsummaries completely happen in the browser, and not on the backend. This kind of sucks, because I would rather just generate the text of the microsummary with PHP. I'm guessing the reason for this is that the the data for the microsummary is cached somewhere and only loaded once. If you want to understand the full power of microsummaries, look into XSL, which is what they use. I'm not going to cover that here, I will only show you how to do it if you simply have a piece of text selected with and id="" tag in your page.

Microsummaries basically contain an instruction on what information from the main page to use. This is specified in the <template> tag. Basically the only thing you need to change in my example is:

Change 'latestArticle' in the id you are using on your site. Next, you need to specify to which pages this microsummary applies. Do this within the <pages> tag. By default every page is exluded. I used this:

This includes every page, but then makes exceptions for the /code section and the /resources (where i store my css/images/etc.)

Selecting these urls is done with Regular Expressions. If you want to understand the full power of this, be sure to google for it. [.]* means a wildcard.

I still need to confirm this out myself if its true, but looking at the updates in the source it seems as if FFMpeg is now injecting FLV metadata in the latest svn sources.. This means we don't have to use a tool like FLVTool2 anymore after transcoding videos.

Also, they decided a while ago to switch from CVS to subversion. Which is nice, because I use SubVersion for all my projects and now I can use ffmpeg as an external definiation.

The best news is yet to come, FFMpeg has 5 projects in Google's Summer of Code. In this program google funds people who are willing to do open source programming for a project of choice. Among those projects is a VC-1 decoder, which allows transcoding WMV3/WMV9, an AAC decoder (AAC is heavily used in MOV/MP4 videos) and an AMR encoder/decoder (AMR is used in 3GP, 3G2).

Good stuff, I've been following the project for a while now and I'm happy to see its still this active.

Although I thought i was well on my way in decoding the AMF3 format, it seems that there's still some stuff not working correctly.

The SabreAMF deserializer is working perfectly, but there's issues with the serializer part.. While the deserializer is built loosely and accomodating for possible bugs from a different serializer, the SabreAMF serializer has to be built as strict as possible. My own produced AMF data seems to decode fine in my own deserializer, but Flex seems to have an issue with it, and throw s and index out of range error.

The guys over at Fluorine (an AMF server implementation for .NET seem to have stuff working in their alpha builds, so I'm going to see if I can learn from their sources or maybe contact them..

A second thing I learned was that there's a 4th object serialization format.. I was aware of 0, 1, and 2 (which are all different formats of serializing objects) but apparently there's also '3'. I noticed this, because I was using Charles for HTTP packages and it threw an exception on me..

Overall it seems that AMF3 is a great format for communication, but also a great overkill for the remoting aspect. The fact is that Flex heavily relies on it, which makes me want to do this, but there are definitly easier ways to encode variables, servicepaths and methodscalls. While they have done a great job in reducing the number of bytes needed to send an integer over the wire, just a simple 'Hello world' call would most likely be tripled or quadrupled in size.. I understand that we are dealing with a messaging service here, and not just a remoting protocol, but do we really need all that overhead when we're dealing with plain methodcalls?

The biggest example I have for this is AMF0 had features for connecting a call to a result (using an id) and a special field for the servicename and methodcall. AMF3 also contains all this information, but its not standing on itself, it is a protocol within AMF0. These fields and information are therefore doubled.. The 'backwards compatibility' doesnt mean much for me, because its still a new protocol to learn, and if you are new in this and want to hop straight to AMF3, you would still need to learn everything about AMF0.

Once there's a final spec for AMF3, which I will try making after SabreAMF is done (and if there isnt a good one already at that point), I will need to write about 4 levels of serialization (the byte level, AMF0 level, AMF3 level and the Messaging class structure). I feel like the classes I made for decoding this are quite efficient and not too-bad structured, but still I need a whole dosen of classes and code just for decoding AMF.. Compare that to the XMLRPC spec, which essentially does the exact same thing, but can be written in 50 lines of code give or take.

A second thing is, that the FlashPlayer first does some kind of ping call, which is a whole new http call.. and requires the entire 4 layer structure to be decoded again.. All it does is checking if the server is up and it receives an acknowledgement.

Essentially that could be encoded as:

"you up?"

and the reply

"yep"

But instead the developers of Adobe decided they need their over-designed over-complex 4-layer AMF protocol .. While my example would be 11 bytes (excluding HTTP wrappers, and all other overhead). Their method of saying the exact same thing requires around 500 bytes.. This might not seem much, but since you can express true or false in 1 byte (1 bit actually) using 250 bytes to just submit true over the wire, is a lot. I wonder why they put so much effort in packing integers in a smaller number of bytes, since basically every other aspect of the protocol grew in bloatyness..

Fair enough, its fun doing this, but it just takes a bit more time to do it..

These are the updates and featured planned for SabreAMF 0.2.

AMF3 - AMF3 support should be in a stable state.. It's quite working already actually (A very big thanks to Karl von Randow for filtering out the last bugs), but at this point its still kind of awkward to use, because you manually need to construct the response object..
Its certainly possible to make this transparent to the user, so this is a big point on the agenda.. If there are any Flex2 / Flash9 people who would like to help testing, drop me a line..

Easier server implementation - I will probably fix something with a callback handler.. Its very important that its still a really minimal library.. But this will not produce a lot of overhead, and makes it easier for user to pick up..

Thats really all.. After this SabreAMF will be 95% percent feature complete.. In any case the core won't change anymore.. After it has been properly tested with Flex2/Flash9 I will mark it 1.0

But first.. off to miami.