Re: [xougen] Regarding server side widgets

[weigelt]

On Fri, Aug 29, 2003 at 03:47:11PM +0200, >> G-LiTe / wrote:

<snip>
> A better way than unix sockets means using another protocol 
> which shouldn't be that hard. 
Yes. Both sides - client library and display server - now speak multiple
protocols (the code could be loaded when needed). On connection startup
the right protocol version is chosen. 

> Implementing widgets server side is totally different level.
> You're talking about the X11 protocol there and not what the X11 protocol
> works on top of and I don't think it'll increase performance that much;
> merely reduce flexibility.
Why ? 
Server side widgets will be optional. They also should be put into an 
separate module, which is loaded on call.

<snip>
> If we change the protocol then it won't really be an X Server anymore.
Not chaning it - putting an new one next to it.

> Adding a different protocol means bloat and sounds silly to me.
> Remember the unix philosophy? Write one good app to do just one thing.
But this does not mean - try to evrything with some protocol from stone
age, which wasnt designed for it.

<snip>
> MPEG streaming is possible, I think. But 3D _really_ can't be done over a
> network, unless you write a wrapper library orso to handle it.
Yes - thats what i want. 
The current 3D libs will be rewritten to allow multiple protocols - 
either using DRI+friends or some X3DNet extension - which does nothing 
more than sending the api calls to the server.
This is of course not as fast as using an local DRI, but better than nothing.

<snip>
> Using 3D means directly writing to video memory and it just won't work
eh ?! thats the current implementation, but no must.

> over a network. Simple as that. Applications using opengl in X don't
> even do it using the X11 protocol.
Well, then they'll learn it. Most 3D applications work over an quite 
small set of 3D libraries - those can be rewritten to be able to use 
an new 3D X extension when required.

<snip>
> >This will be an multiprotocol server, you know that ?
> >
> And that is why I'm against it. I'd rather provide the functionality to
> applications, ie. the XDamage extension sounds like a very good idea to me.
But costs performance. If we do it directly in the server process, we
dont need to encapsulate it and post it through sockets anylonger. 

Look at other things like webservers - httpd-2 is an multiprotocol server,
and it works.

<snip>
> >Are you talking about an new lib or an new interface ? That's completely
> >different.
> > 
> Already in the works as somebody else said: XCB.
> See xwin's / freedesktop's wiki.
I've currently not the time for looking at this (i also have to fight against
software patents) - so could you please explain it in short words ?

<snip>
> >ACK. The whole distribution should be splitted into smaller packages.
> >So we i.e. have some Xcommon, Xserver-framework, Xserver-card1, 
> >Xserver-card2, ..., Xserver-mouse, ...
> > 
> That's impossible. All these components use the X11 protocol and it's
> thus much easier to have it handled by a single application.
> Seperating the backends is a different thing though, and I have no problem
> with that.
No, it seems we're talking about diffent things.
I want to split up the X sourcetree (and also the binary packages) into 
smaller parts. 

for example:

* generic X shared stuff like protocol handling (xbase)
* client library (xlib)
* server framework (xserver-base)
* server loader (xserver-loader)
* video drivers (xserver-video-...)
* input drivers (xserver-input-...)
* several applications ...

Most of the things I'm talking about are already separate libraries, 
but I'd like to have them separated in the sourcetree - so one can
download only those parts he/she really wants.
I dont need drivers for thousands of video cards I do not own.

cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux ITS 
 Webhosting ab 5 EUR/Monat.          UUCP, rawIP und vieles mehr.

 phone:     +49 36207 519931         www:       http://www.metux.de/     
 fax:       +49 36207 519932         email:     address@hidden
 cellphone: +49 174 7066481          
---------------------------------------------------------------------
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/