queing is implemented in X but...
on
Low-Bandwidth X
·
· Score: 3
Actually newer generations of X servers queue protocol messages to a batch of many requests/replies to address this problem. The problem is, in real world applications this doesn't work out very well because of the way Xlib programs are written.
The low level implementation of X programs requires a linear flow of
REQUEST info A, SET property B, REQUEST info C, REQUEST info D, SET property E
, and so on...
Because there is no way for client nor server to understand which information/property depends on any preceding, the protocol messages have to be processed one after the other.
In cases like requests to set/request a large set of similar properties (e.g. color information), queuing takes place and messages are sent containing a whole batch of single events, but this doesn't happen often in real world applications, thus not noticably increasing performance.
The X protocol was not designed for an asynchronous message flow.
Re:Freshmeat vs. Sourceforge, boxes on FMII
on
Freshmeat II
·
· Score: 1
Just to agree with somebody else in this thread, Freshmeat is indeed better than Sourceforge. This is not a flame, it's just my belief that Sourceforge needs to get more bandwidth...
Comparing fm to sf is like apples to bananas. While you may be right that sf could use more bandwidth, it's scope is far beyond that of fm.
fm solely offers an application index while sf primary targets project hosting services, like CVS, HTTP, FTP, managment interfaces,...and all that for free!
Slashdot Mirror
The low level implementation of X programs requires a linear flow of
, and so on...
Because there is no way for client nor server to understand which information/property depends on any preceding, the protocol messages have to be processed one after the other.
In cases like requests to set/request a large set of similar properties (e.g. color information), queuing takes place and messages are sent containing a whole batch of single events, but this doesn't happen often in real world applications, thus not noticably increasing performance.
The X protocol was not designed for an asynchronous message flow.
Comparing fm to sf is like apples to bananas. While you may be right that sf could use more bandwidth, it's scope is far beyond that of fm.
fm solely offers an application index while sf primary targets project hosting services, like CVS, HTTP, FTP, managment interfaces,...and all that for free!