GothAck / javascript-x-server

JavaScript X Server (current protocol prototyping in Node.js, hoping to port to HTML5 for graphics)
Other
127 stars 17 forks source link

combine efforts? #1

Open mscdex opened 11 years ago

mscdex commented 11 years ago

Have you seen this? It'd be great if both of you could combine efforts to have something for both the web and desktop.

GothAck commented 11 years ago

Apologies for the delay responding, yes I have seen, and will contact the dev to see what we can work out :)

sidorares commented 11 years ago

wow. 7 month ago and I actually was going to contact you (and I think have sent email, can't remember to which address)

If you don't mind, I'll outline here possible areas of collaboration and we'll break into sub issues later

1) I started some work on generating js parser from xcb xml protocol description https://github.com/sidorares/node-x11/tree/master/autogen. We could generate client and server side of X11 parser from it as well as browser and node versions 2) I'm very keen to be able to run x11 examples in browser without actually serialising to x11 protocol. I don't like current api in node-x11 (it's very low level and not stable enough). Something like https://github.com/sidorares/ntk might be better (see examples) 3) Another crazy idea: JS scripting extension for XOrg. Upload your widgets js to server similarly like you upload shaders to GPU or js to browser and make X programs super responsive even on slow connection. 4) Another proof of concept I'd like to try - XNest/Xephyr-like application built in pure JS 5) For X server in the browser I'd really like to see accelerated GLX via webgl. Note that indirect glx uses it's own serialisation format for gl commands - see https://github.com/sidorares/node-x11/blob/master/lib/ext/glxrender.js

GothAck commented 11 years ago

Hello!

Sorry it's taken so long to reply, life is pretty hectic here at the moment, but finally I've remembered >_<

Sounds like a good plan, would love some involvement, have lots of ideas for the project, but it was put on hold for a while. I'll respond to your points as it'll be easier for my brain :D

1) I came across your project when I first started out, however at the time I wanted to know how the protocol worked from the inside out, hence why I started {de,en}coding myself... Things have moved on from that point, and I'm frankly fed up with doing so :D I've recently (mostly) split the protocol layer into it's own WebWorker within the client, it's made lots of things lots simpler, keeping the protocol impl separate from the processing and rendering! Maybe we can look at plugging the XCB layer in there, and autogenerate the protocol? 2) Yup, that sounds good, take a look at the interaction between the worker and the main process, it's still quite low level, but we should be able to create a wrapper around it? Maybe we can run such a thing in a shared worker for all to access? 3) Sounds really cool, and if we engineer the server correctly, should be implementable, maybe we can flesh that out later on :) 4) Wow, sounds awesome too, should be very possible, especially if we get the main server pluggable, could even run the Xnest as a separate app in it's own workers, using the same interface as point 2! 5) Haha, had the same idea, definitely sounds good, however will be fun mapping the GL->WebGL as their APIs are, using my little knowledge on the subject, a little different. Definitely possible though!

Also have one other idea... PulseAudio, for all it's down sides, can stream mp3 out, this could be streamed to the browser and use an audio element to play, could become a very interesting extension to the server, not really X11, but would sit nicely beside it.

How does all that sound? Would definitely love some external involvement as the process has been very organic, and has now turned from a learning exercise into a larger project, with lots of potential!

Speak soon,

Greg

sidorares commented 11 years ago

Whoa! :) Thanks for reply (and it takes long time for me, too, sometimes)

For me the main point was learning X guts, very similar to your goals. I'm really happy that you like my ideas. (and I was actually thinking about PulseAudio proxy to browser some time ago!)

Probably XCB xml generation would be a best starting point for collaboration

I'll try again to install js-x-server tomorrow (had some troubles with fonts 6 month ago, got it running eventually but with some issues, can't remember)

Talk to you soon!

Andrey

GothAck commented 11 years ago

Yo, that was quick :D

X guts are very interesting, but protocol guts get a little tedious after a while ;) we seem to be on the same wavelength, which is awesome!

I'm taking a look at the generation at the moment, would like to suggest that I implement a node and browser version of my EndianBuffer implementation, deals with swapping endianess in a much easier form. Will see if I can get that split out today.

If you need any hints of a zipped copy of the fonts subproject, drop me a line and I'll get something sorted. It's been a while since I last converted the fonts, so that project might have fallen behind.

Greg

sidorares commented 11 years ago

<super quick mode on before going to sleep> https://github.com/CrypticSwarm/XCBJS - some work started here on xcb parsing I'm using simple async binary reader lib for node - https://github.com/sidorares/node-unpack (format borrowed from python unpack). In my node-x11 I completely ignore endianness atm as all server I tried of same endianness. For me there is probably no point in EndianBuffer as it should be a flag to unpack library I'll give you more feedback after I try to use server tomorrow

ttys <super quick mode off>

GothAck commented 11 years ago

Servers pick the endianness from the client's initial connection setup, although I could ignore the endianness, I'd prefer to support as much as the protocol / browser will allow :) (as a client you're free to pick whichever you choose)

ttys