On Tue, 23 Jul 2002 00:39:54 +0200 Vincent Touquet <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 22, 2002 at 07:17:27PM -0300, Juan Linietsky wrote: > (cut) > >How do you think the implementation should be? I cant think of > >much, but > >i think even a simple communication protocol that can send > >tree-organized data > >between apps over either tcp or unix sockets should be enough.. > >Also this > >way it could save/load data from XML files. I think XML is very > >important for this > >because 1-It's standard 2-If we dont use it, We'll have all the xml > >lovers saying > >the lib is crap because it doesnt use XML ;) > (cut) > > XML of course :) > > There are those who claim XML is bloat though ;) > > Nothing is more portable than xml though. > > Hell, we could be even using Jabber and > save / recover state using our own XML based > protocol across multiple machines... > > This could be made very versatile :) > > So we have: > > - audio interconnection -> JACK > - control interconnection -> ? (alsa ?) Alsa I guess.. Alsa does midi, but midi proovides timing and start/stop commands so i think control is by default something inhertent to midi. External equipment you can buy also uses midi for this. > - state saving protocol > -> some XML based protocol > > Is this XML based protocol restricted > to state accounting only or would it > be used for control interconnection > protocol too (like midi + some bracket bloat ;) ? > I dont know if the protocol should be xml itself, i was talking about the state files it saves. I think by just using a tree-based data container protocol for communication is enough.. I dont think the lib has to get complicated unnecesarily. I'd also limit it for state load / state saving for now. I know it would be cool to have an xml transport system, but i think the best is to start with a very simple lib that proovides the needed functionality for programs and just that.. if we see that something more useful could be done, then version 2.0 will do that ;) Juan Linietsky
