J5’s Blog

May 21, 2010

Let’s get this staight – MPEG-LA’s and an x264 developer’s sabre rattling is pure FUD

Filed under: Open Formats, Standards, video — J5 @ 12:13 pm

Unless you have been living under an Internet rock you already know that Google just released VP8 as an open source and open standard protocol. Almost instantly over night the video codec ecosystem has been turned on its head as Mozilla, Opera, YouTube and Flash, among others have already pledged support and even got tech previews up and running.

It is also no surprise that the MPEG-LA and x264 developers are hitting back. What is of concern is people take these bias sources as fact. The issue is the arguments used to scare us away from moving to a format that they do not control or develop, either hold very little water or apply just as much to using MPEG-LA technologies as it does to VP8 technologies, with the caveat that you have to pay for the privilege.

For instance the assertion that you can never be 100% sure something is patent free (or more precise you have the rights to use a technology without fear of litigation) is on the surface true. Our patent system is fatally flawed in that it is over broad and largely opaque. One can never be sure that some patent might surface or a jury might interpret a patent in a way that is more favourable to the patent holder. The issue with the argument is it applies just as much to H.264 as it does to both Theora and VP8. It is a straw man argument. The logic follows very closely to extortion (legalized because of the flawed patent system) – if you pay us money and use our services we will ignore you but if you go somewhere else we might start harassing you, so you are safe if you stay with us, if you catch my drift. What we do know for a fact is organizations such as Google, Mozilla, Opera and Adobe, all of who have very capable team of lawyers, have come to the conclusion that it is safe to ship the utilize the VP8 codec.

As for the argument that hardware manufactures already support H.264, we wouldn’t get anywhere if we just accepted the status quo. If you look at the list of organizations supporting WebM you will see that they are not only heavy hitters, there is also a good number of them that are hardware vendors. I’m pretty sure we will see android devices coming out in the near future that support the format in the base system (and I’m sure we will see apps and plugins pop up almost instantly).

What about technical arguments that VP8 just isn’t good enough yet? Those arguments came from an x264 developer. (side note – x264 is an Open Source implementation of the H.264 format. While the code itself is under an Open Source license the usage of such code is not open as it is governed by the MPEG-LA patent portfolio). Good enough is a pretty subjective thing. Google seems to think it is good enough for YouTube and as we have seen with the improvements in Theora which started out as a pretty low quality encoder, a little time and effort is all that is needed. Unlike Theora however, which is reaching the upper level of constraints imposed on it by the format, VP8 is at the low end of its potential. With a modern video codec design and more interest due to the open sourcing of VP8, we can expect a stead stream of improvements to the encoder for years to come.

In the end this will all come down to supported codecs. Right now H.264 has the lead but with Google’s YouTube on board as well as all the major browsers which have rising market share, that might not be the case forever. MPEG-LA and H.264 developers will continue to sabre rattle in hopes that their FUD will scare off users instead of actually competing. Here is an idea, why not license H.264 in a more market friendly model? You know one, that doesn’t threaten and extort users and developers? I’m not holding my breath for that one.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]

May 19, 2010

PyGI: where we are at and what have I been up to

Filed under: Gnome, Python, Standards — J5 @ 11:56 am

Well it has been awhile since we had the awesomely productive GNOME Python hackfest and now we have a roadmap and people working on getting out releases of the various components. At first I came in as a concerned citizen who just was just a consumer of the Python stack. I thought I would just organize a hackfest, attend a couple of days and everything would work itself out. I find naiveté helpful when getting started in a project because if I walked in knowing the amount of work involved I would start whistling, make a sharp U turn and hope nobody noticed me running for the hills.

As it stands I am lucky enough to have a Manager who realizes the importance of the GNOME Python stack (given that a lot of Red Hat’s tools including the installer are based off of them). Fedora 13 already has a parallel installable Python 3.1 stack and since we are targeting Fedora 14 to get as many major modules ported as possible, I have been give permission to work full time on the GNOME bits.

So what exactly have I been up to?

I’ve been working on porting PyGTK apps to PyGI with an eye towards fixing up the PyGI API through the overrides, finding and fixing bugs and adding binding friendly API’s directly to GTK+ (as well as fixing up some of the introspection annotations).

Where am I at?

I am happy to say that yesterday I managed to squash what seems to be the last of the memory crasher bugs that have been frustrating my API fixing efforts. They still need to either be vetted or are waiting on other patches to be incorporated into git so for now you can apply the patches in bugs 617780, 618049, 619007 and 583909. Actually the last two patches are redundant, the latter being the correct patch and the former being the patch we will go with if pygobject take some time to approve. PyGObject is a lot more risk averse since the PyGTK static bindings also relies on its API being stable.

I am also pretty sure that most of the GtkBuilder/GtkUIManager stack is now usable with minimal porting efforts from PyGTK. I should be pushing most of my override work into git fairly soon (I need to write test cases). One issue is they rely on patches to GTK such as the one in bug 61857 which won’t be in GTK until the 3.0 release. This leads to another issue of finding all the needed API changes. Since GTK is on a 9-12 month release cycle, not to mention API freeze dates, it might be hard to find all the API that needs adding in order to be binding friendly. Bellow I will talk about some strategies to deal with this.

What needs to be done and where can others help?

The biggest hurdle to making PyGI usable is gaps in API coverage. Because PyGI’s API is mostly auto-generated on the fly it doesn’t always get things right or throws in a lot of C’isms which are confusing in a Python world. Some APIs just plain can’t be wrapped correctly and will lead to refcounting errors and ultimately crashes. PyGTK on the other hand has been developed for many years and each API has evolved to fit within the Python world. Some are APIs better wrapped than others but I digress. What needs to be done is port small PyGTK examples that utilized different parts of the GTK+ API. For things that don’t work we need to file bugs and write overrides for those pieces of API. We are not aiming for a 1 to 1 port of PyGTK. For instance PyGI’s handling of constants, enums and flags is much nicer and more complete than PyGTK. What we are aiming for is to make it easy enough to port applications and to be able to fully utilize the GTK API.

As for patches to GTK goes I think we should have a two pronged approach. We should create a compat library that adds the needed API fixes but prefer API inside of GTK itself. The compat library will be for internal override use only and anything going into the compat library must first have a bug and patch filed against GTK. As we get a larger coverage inside of GTK, all new GTK APIs are vetted for scritability issues and distributions start removing support for older versions of GTK we can drop the compat library.

We also need people to read and vet patches as well as usher them through the approval process. Getting patches through quickly to meet schedules is very important. Helping to write tests for patches will also speed up the approval process.

Do I see any roadblocks in the way?

My number one biggest concern is the Tree and List model/view API. It is packed with C’isms so requires a lot of hand holding to wrap correctly. Also PyGTK has a rich, completely custom, tree API because of this. That means for the most part we have to hand write and maintain a lot of code in order to get the API into a usable state. I already took a crack at it but got frustrated when trying to wrap parts that used iters. It is all doable but in the end even PyGTK had to make some hard decisions (using TreeIters will almost certainly cause a leak). Does anyone want to write a new script friendly Tree API? I find this issue to be the dragon standing in the way of getting PyGI to a usable state. Let’s just hope it doesn’t turn into a windmill.

Where can someone ask questions and offer to help?

Right now the best place is #pygi on GIMPNet/irc.gnome.org. We are in the process of creating a mailing list and will inform everyone once it is up.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]

January 28, 2010

kamaloka-js 0.9.0 released

Filed under: AMQP, Open Formats, Standards, messaging — J5 @ 5:04 pm

I am proud to announce the second release of the kamaloka-js AMQP bindings. This release brings with it a high level API modeled after the new Sender/Receiver and addressing API’s being developed in the Qpid project. It is intended to bridge the gap between the 0.10 protocol and the upcoming 1.0 protocol. I have also simplified the code base and improved the code generator. Because we are getting so close to implementing the complete 0.10 protocol spec, we have bumped the version to the 0.9.x series to indicate a redefined focus on stabilizing the current code base. You will notice significant API changes from 0.1.0 to 0.9.0. We hope to not have to make too many more changes during the current cycle of development and hope to get a 0.10 version out once we have completed coverage of the entire spec.

Some of the highlights of this release are:

  • Rework API to conform to the new Sender/Reciever API and addressing format
  • Supports multi-channel/multi-frame parts of the spec
  • Uses js.io class infrastructure
  • Generated code now easier to read with decoders implemented in a class hierarchy
  • Rewritten dispatch layer – event code now works on the message layer instead of the frame layer even for low level dispatching
  • Much closer to implementing 100% of the 0.10 spec
  • Infrastructure in place to start working on the 1.0 spec

Give me the code

About Kamaloka-js

Kamaloka-js is an implementation of the AMQP messaging protocol in native JavaScript. It is setup to be used with Orbited but can be used with any library which produce TCPSockets in the browser similar to Orbited. Kamaloka bindings are generated from qpid XML protocol description files.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]

January 27, 2010

Flattening the model

Filed under: AMQP, Open Formats, Standards, messaging, performance, tubes — J5 @ 5:14 pm

In my quest for cleaner code in Kamaloka-js I have been working on simplifying the dispatch model.  AMQP has some interesting features built into it to facilitate real-time functionality along with message prioritization.  To accomplish this messages can be sent on different queues and tracks, and also be broken up into segments which can be further broken up into frames.

Frames

Frames are the basic building blocks of the AMQP data stream.  They contain complete headers that describe queue, track and segment that is currently being constructed.  The payload of a frame (the segment being built) can be broken up into arbitrary sized byte arrays which are then reassembled based on the channel and track they are sent on.  In this way applications with memory constraints can request that frames be no bigger than what the application can fit in memory.  A typical frame header looks something like:

{
  channel: 0,
  track:1,
  is_first_frame: 1,
  is_last_frame: 1,
  is_first_segment: 1,
  is_last_segment: 1
}

Segments

Segments are like frames but instead of an arbitrary split on a data size, each segment is split on struct boundaries. That is to say, when you receive a complete segment you can be sure that it can be fully parsed. There are currently four segment types: A control segment, command segment, header segment and body segment. Command messages are currently the only type that can contain a header and body segment. For instance, the transfer command is used to send messages to and from a queue. It would contain header segments which could be used to route the entire message and it would contain a body segment which contains arbitrary data the user application cared about. Each segment is broken up into at least one frame. Multiple segments would never be sent in a single frame.

Channel and Tracks

A channel is just an integer that denotes related frames and segments. One can think of each channel being a list of incoming frames which are ordered correctly. Once the last frame in a channel is seen, the message is constructed and the channel is flushed and ready to receive a new message. In this way, multiple messages can be received at the same time by utilizing different channels but only one message can be sent on a single channel at a time.

Tracks are an exception to the one message per channel rule. There are two tracks in the current spec. The control track (track 0) and the command track (track 1). Controls preempt commands on a channel, so you can be in the middle of receiving frames on the command track and a control can come in on the control track and you must respond to that first.

This all sounds complicated but you can just think of the channel/track combination as being one entry in an hash. For instance frames coming into channel 0 and track 1 would be given the hash “0.1″:

message_channels["0.1"].add_frame(incoming)

First pass – Frame dispatching

At first it was easier to think of the frame and segment issues as different layers. At the lowest layer I would decode and dispatch each frame and then pass it off to the segment layer once a complete segment had been decoded. The segment layer would then collect the segments, relate them to each other, and then construct the full message. The frame layer looked something like this:

Flowchart showing the frame decoding layer of the kamaloka-js AMQP bindings

Flowchart showing the frame decoding layer of the kamaloka-js AMQP bindings

The dispatch would then pass it off to the segment decoder.

This became overly complicated because each segment had varying degrees of metadata and the body and header segments didn’t map to the message object very well. I could have gone ahead and created a segment object but I wanted to simplify the code.

Flattening the frame and segment layers

As it turned out flattening the model only added a couple of more steps to the current frame layer. Since frames and segments are just two different ways of breaking up a message for transfer over the wire, combining the two in the same layer made sense. What I ended up with was this:

Flowchart showing how the Kamaloka-js AMQP bindings decode frame and segments into a message

Flowchart showing how the Kamaloka-js AMQP bindings decode frame and segments into a message

If you notice I now only create a new message if it is the first frame and first segment on a channel. When I see it is the last frame I incrementally decode the segment but I only dispatch the message once the last segment is seen. In the end, these minor adjustments allowed me to strip out a whole layer of redundant code. It also simplified the low level event code as I used to have to manage callbacks for each segment in order to construct a message. Now events only trigger once a full message is received and not when each frame or segment is received.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]

November 23, 2009

FUDCon, the AMQP story

Filed under: AMQP, Standards, conference, messaging, tubes — J5 @ 7:41 pm

With FUDCon being only two weeks away, I’ve been polishing up my presentation and looking into what is in store for the future of Fedora’s Infrastructure. My main focus has been adding “push” capabilities throughout our infrastructure via the use of the AMQP protocol and qpid servers.

So why do we care about push messaging?

One can think of messaging as a conversation between two people. Poll messaging goes something like this:

Poll Messaging

Push on the other hand is a bit less chatty:

Push Messaging

By eliminating the need to poll to know when an event has happened within Fedora’s Infrastucture, and making it easy for services to push out events in an easy fire and forget manner, we open up the door to a number of interesting possibilities. For instance, instead of implementing mail notification functionality in every service we simply create a mail notification service that listens for events and sends e-mails to people who what them. Do you want to get a notification on your desktop when your build is done instead? This makes it possible to provide that functionality without bogging down the Koji build service.

Human consumable notifications isn’t the only advantage of adding push messaging to our infrastructure. Because the data is first formatted for services to consume, notifications can be used for things like automation and synchronization. For instance someone could write a script that listens for new git checkins at fedorahosted.org and tries to package it into a private repo for personal testing.

What do we need to discuss at FUDCon?

Though this change is minimally invasive and you can ignore it if you don’t need to work with notifications, it is never the less a large undertaking. Some of the things we need to discuss are:

  • Usecases – where can we benefit by adding notifications?  How do we envision the notifications will be consumed?
  • Payload format – what are the pros and cons of the different ways we can encode and decode data
  • Standardization – even though we have a routing protocol we still need to standardize on the type of data to expect
  • Libraries – we need to make it dirt easy for infrastructure developers to add notifications to their service
  • Performance and security concerns – AMQP is pretty complex so we will need to make sure all of our bases are covered when deploying the QPID servers

AMQP Sessions at FUDCon

There are a couple of talks planned and a hackfest.  Come to the talks to get a deeper understanding of AMQP and how we envision using it within Fedora and then attend the hackfest to help us map out the future of the Fedora Messaging Infrastructure.

Saturday:

  • AMQP Messaging for Fedora Developers – come to my session to find out the basics of AMQP messaging and how it is relevant to Fedora’s infrastructure
  • AMQP/Qpid on Fedora – The definitive guide – get a more in-depth view of AMQP in Rajith Attapattu session.  He will show you how to setup and configure the Qpid server on Fedora, use the client APIs, and where to go to find help when using AMQP.

Sunday and/or Monday:

  • Get on the (Message) BUS Hackfest! – come to Jesse Keating’s hackfest to work out details and hack on the messaging infrastructure.
[read this post in: ar de es fr it ja ko pt ru zh-CN ]

September 23, 2009

kamaloka-js-0.1.0 AMQP bindings released

Filed under: AMQP, JavaScript, Open Formats, Standards, messaging, webapps — J5 @ 5:38 pm

I am proud to announce version 0.1.0 of the kamaloka-js AMQP bindings. This initial release is considered to be an alpha quality release. It is there for you to break and give feedback so we can continue to improve the bindings and eventually get them to the point where they can be used to run mission critical applications.

In the next few days I will be concentrating on documenting the design of the bindings so anyone who wants to can easily jump in and contribute patches as well as suggestions. Please visit the project page to find out more and see how you can help out.

What’s in store for the future?

  • High level bindings for each of the major AMQP client patterns to get developers up and running with AMQP in the browser fast
  • QMF bindings for working with the QMF management console

Where can I find this release?

What’s in this release?

  • Initial release
  • Connection handshaking works
  • AMQP lowlevel bindings for version 0.10 of the AMQP Protocol mostly complete
  • Higher level bindings implementing the publisher/subscriber pattern is ready for use

How can I find out more?

Kamaloka-js is an implementation of the AMQP messaging protocol (http://amqp.org/) in native JavaScript released under the MIT license. It is setup to be used with Orbited (http://orbited.org/) but can be used with any library which produce TCPSockets in the browser similar to Orbited. Kamaloka bindings are generated from qpid XML protocol description files.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]

August 26, 2009

Home is where the heart is

Filed under: Open Formats, Standards, messaging, tubes, webapps — J5 @ 9:59 pm

I managed to make it home in one piece from Vegas and dove right back into work. After getting away from messaging for a bit I have come full circle but with a little bit of a twist. In an effort to bring some of the goodness that is interprocess messaging to the interwebs – similar to what we get on the desktop with D-Bus – I am implementing the standard AMQP protocol in native JavaScript.

This along with QMF will give us the ability to send out notifications of events, monitor statistics and eventually supplement REST and XML-RPC interfaces with more efficient multi-response method calling (imagine streaming rows of data instead of waiting for the entire row set to be sent).

AMQP Handshake over Orbited

AMQP Handshake over Orbited

Above is a little hex dump web app I wrote to test the bindings. What you see is the start of the AMQP handshake. First I send the header indicating the version of the protocol I am expecting. I then get the ’start’ response back stating the capabilities of the broker I have connected to. I then send the ’start-ok’ packet indicating what auth mechanisms I support and the locale (I would also send a token if I were using a particular auth other than anonymous).

That is about as far as I have gotten but since the bindings are autogenerated from an XML description of the protocol most of the control and command classes are implemented. There are still some types I am trying to figure out how to support (the supported types are a magnitude above what was needed for D-Bus) and I need to smooth out the rough edges as well as write the higher level user bindings but I am off to a good start.

Code will be posted as soon as the project resources are approved and setup. Keep watching my blog for updates.

BTW: The slow response times in the time stamps are due to running inside of the firebug debugger and writing out the hex dumps on the fly using JQuery. It seems the more sophisticated JQuery and Firebug get, the more they butt heads.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]

May 29, 2009

Open Video Conference

Filed under: Gnome, Open Formats, Standards, community, conference — J5 @ 1:20 pm

As a culmination of all the positive momentum that has been going on the past few years all the important Open Video players will be gathering at NYU’s law center for the first of hopefully many Open Video Conferences on June 19th.

The interesting part of this conference is it isn’t exclusively a tech conference. According to their website:

Open Video is a broad-based movement of video creators, technologists, academics, filmmakers, entrepreneurs, activists, remixers, and many others. When most folks think of “open,” they think of open source and open codecs. They’re right—but there’s much more to Open Video. Open Video is the growing movement for transparency, interoperability, and further decentralization in online video. These qualities provide more fertile ground for independent producers, bottom-up innovation, and greater protection for free speech online.

If we have any hopes of success in bringing the general public an understanding of our views on the importance of openness and freedom, forming a larger community with like minded content creators is the next logical step and another piece of the puzzle.

I will be attending the conference as a representative for GNOME. Others should consider registering and attending to represent their own media minded project. I hope to see you there.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]

February 24, 2009

The Economics of Time and Effort

Filed under: Standards, community, usability — J5 @ 1:14 pm

When people think about economics they usually just think in terms of money but economics is about understanding the flow of limited resources within systems in an effort to make those systems more efficient (or if you are cynical making those systems be more efficient for a specific group). Money is just a system we have used to quantify the worth of those resources to counteract the inefficiencies of bartering. Since money has the ability to be traded for almost any resource (including money itself) it holds a lot of power and has become the focus of most of economics.

However, in the Open Source community a majority of our transactions do not include money. At least not directly. In fact, a majority of our capital is payed in the measure of time and effort; both by the consumers and producers. Both are highly limited resources which in the Open Source world aren’t really given the thought they deserve.

First consumers often give the impression that they think producers have all the time and energy in the world but only a small portion of the community can be classified as producers, and even a smaller subset are full time producers. The only way to grow time and energy in an efficient way is to get more people to become producers. The power of Open Source is not that it is freely available but that anyone can become a producer. Providing that producers work together in some sense of a direction, Open Source growth should be exponential and eventually overtake proprietary development in terms of an efficient economic model and generation of capital. That is why the GPL and other reciprocal licenses are in the long term a better model as they prevent the “picking up and going home once the market expands” syndrome – though there are other forces that effectively prevent that for projects under other licenses. That is all another post though.

The other place where both time and effort are not given enough thought is in the use of the final product. In fact many projects fail to productize their efforts, choosing to leave that up to vendors. I cringe when I hear things like, Linux can do anything you want, you just have to configure XYZ. I don’t know anyone who truly wants something that can do everything. They want something that can do what they want without too much time and effort put into it. Every time we require our users to expend time and effort that is resources they are spending. If the cost is too high they will simply look elsewhere. Believe it or not, the worth of time and effort are readily quantifiable by looking how much people spend a year on unneeded conveniences. It is pretty high.

An example of time and energy wasted is logging into open services. Logins are inevitable but why in a world that prides itself on community are we beaten to the single signon party by the likes of MS Passport or Google checkout? Taking an example from Sound Juicer, the cd ripping app, I have a number of cds which I pick up at local venues because I heard something I liked when walking by. Sound Juicer gives you the option to upload track info to the MusicBrainz database. Unfortunately all this option does is bring me to a login/signup screen after I took the time to enter in all of the track data. Having to get yet another account for something I don’t really care about anymore because I already have the track info is just too much effort to spend so I end up just closing the browser window. Sound Juicer and MusicBrainz does get the consumer seal of approval for making it easy to grab track info when ripping my cds but they missed an opportunity to convert me into a producer which would bring even more value to their consumers. In fact the track grabbing functionality is so transparent – no configurations needed, no extra actions are required – that it is a quintessential example of how an app should be productized. Why adding to the DB isn’t more wiki like or federated with other open services, such as wikipedia, slashdot, lwn, distributions, etc. is somewhat of a mystery. It isn’t a mystery altogether though -

Time and effort on the producer side needs to grow and producers need to work closer together, building bridges instead of just looking to grow their own little island. The Open Source ecosystem, while priding itself on community has often neglected to build technology which works like a community. More cohesion between these islands allows them to grow and innovate on their own but still act as an integrated/efficient experience for the user, minimizing the time and effort it takes to use our software. By having an integrated experience all the way to the producer level we have more of a chance to convert consumers to producers thereby adding more time and effort capital to the entire ecosystem. Make it easier to both consume and produce in the Open Source ecosystem and traditional economics will take over to propel it to the mainstream as it has done in small subsets such as in the business server market.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]

December 1, 2008

JavaScript, I really want to love you but…

Filed under: Standards, usability — J5 @ 6:17 pm

Ok so it isn’t all JavaScripts fault and Mozilla’s ‘let’ keyword might have just solved some of this if everyone would just support it, but take a look at this bit of hack I had to write.

public_methods: ["insert_row", "append_row", "remove_row", "json_load"],
    public_signals: ["ready"],
    bind_api: function(api_list) {
        var self = this;
        for (var i in api_list) {
            var pm = api_list[i];
            var name = pm + ".mokshagrid";

            // proxy pattern (used for javascripts busted scoping rules)
            (function() {
                var proxied = self[pm];
                if (!proxied)
                    throw ('ERROR: binding api "' + pm + '" failed - method does not exist.'); 

                self.element.unbind(name).bind(name,
                    function() {
                        return proxied.apply(self, arguments);
                    });
            })();
        }
    },

It is a convenience method for binding public API in my jQuery.UI plugins which require the use of the 'trigger' method in order to call into a widget from external code. In other words jQuery.UI treats signals and public methods all as part of their event system. A bit confusing but not a huge deal. This would all be unnecessary if there was a better OO model on top of the prototype model. I'll admit the prototype model allows for some cool stuff but there is a reason everyone is jumping to write an OO model on top and why everyone is doing it differently.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]
Older Posts »

Powered by WordPress