KNotificationItem specification - first draft

[Jon A. Cruz]

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.