On Tue, 2006-08-29 at 23:32 -0400, Frank Brickle wrote: > Bob -- > > If it's OK with you I'm taking the conversation public again, for the > time being anyway. > No problem with that at all.
> > Could we for example agree that there is a distributed infrastructure > > (regardless of language, protocol or encoding formats) in which services > > are hosted and that services communicate with each other through this > > infrastructure by asynchronous messaging. I would like to give it a > > name, say RSA (Radio Services Architecture) and define it properly so we > > have a frame of reference. > > We're a ways away from being able to give a name like Radio Services > Architecture, yet, I think. > Ok. On reflection defer the name until we have something to name. > For a number of reasons, I propose we begin with what I'll call the > Radio Space. This seem like an appropriate term? It's metaphorically > suggestive. It's also the right concept formally, too, I believe, since > an SDR "application" will turn out in the end to be, precisely, a > topology on the Radio Space. > Yes, I like that. Java coined the phrase Space in its Java Spaces which is also a distributed architecture. Just to make it clear there is no connection. > The points in the Radio Space are the functional nodes we've been > talking about -- the DSP, the hardware control, the audio subsystem, > pieces of the UI, etc. We will probably find it useful to flip-flop back > and forth as convenient between thinking of these components as points > or as nodes, with the Space and the topology being either point sets or > graphs. > I think it would be useful, certainly for me to have a glossary of terms as we proceed. I think we have introduced so far: space, topology, service, process, node, point, graph, point set, composition, orchestration, protocol, encoding format, messaging. What about moving agreed stuff into a document as we proceed so we have more than just a long thread at the end. This should probably be on-line somewhere, perhaps a Wiki would be an appropriate medium. > So where we start is with a bunch of nodes but no edges connecting the > nodes. There's no hierarchy or layering yet, merely a bunch of > functional components that can be made to pass messages among one > another. > Agreed, whether the composition is flat or hierarchical and exactly how messaging is achieved is not material at this level. > > Services are composeable, that is they can be orchestrated to produce a > > working application. > > Yes. In these terms, a compositional grouping of components amounts to > inducing a coarser topology on the Radio Space. In practical terms, it > amounts to having a way to wrap them together so as to be able to deal > with them as if they were a single functional unit. > Yes, it's just levels of abstraction so people who know certain areas well can compose those services into an abstraction that the next layer can work with more easily. > All right so far? > Yes, excellent. I think its a good start. Of course this is not a small subject and there are many places we could go next. Would it be sensible to create a topics list first so we don't get bogged down on one issue. I think working both ends towards the middle is also a good policy so hot issues can have a proof-of-concept in parallel to the thought process. 73 Bob G3UKB _______________________________________________ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
