Or use something like SOAP? As long as theres a mechanism for naming the source application and if needed it's instance, then there shouldn't be a problem. Something like:
<Config id="dpromix01" node="aabbccdd"> ..... data ..... </Config> -P Juan Linietsky wrote: > 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
