KNotificationItem specification - first draft

[Marco Martin]

On Monday 07 September 2009, Jon A. Cruz wrote:
> On Sep 7, 2009, at 11:54 AM, Marco Martin wrote:
> > now i'm not sure about the current status of the tcp transport of
> > dbus, but
> > once it works i don't see particular problems, big endian machines
> > would have
> > to invert the bytes of the image by hand, that is something that
> > somebody will
> > inevitably have to do in a mixed environment. i think it's possible
> > to avoid
> > an extra field for that anyways
>
> A general approach has been to define things as network byte order...
> aka big-endian.
>
> Regardless, it should be made explicit and the future use explicitly
> covered. If I recall correctly, X11 address this for datatypes by
> being explicit about data types and sizes, and then for multi-byte
> values the system automatically handles client/server differences in
> byte order.
>
> This does come up for clipboard and drag-n-drop operations also. In
> fact, I recall having some problems with Qt/KDE color types not being
> defined correctly. The color format was 16-bit component values, but
> Qt/KDE gave 8-bit format for the 16-bit data. In that case 16-bit
> format would be converted automatically by the transport, but 8-bit
> format required some kludges and trying to standardize on the byte
> order, etc. The most likely cause was simply oversight on the part of
> Trolltech, combined with not enough time/resources to run some
> heterogenous tests.
>
> It probably would be good if new protocols would avoid problems
> initially. Then we won't have to add work-arounds and such later.

just to keep things updated..
i've put the requirement of images in network byte order in the current rev of 
the spec and updated our implementation accordingly

Cheers,
Marco Martin