The observer design pattern is a prerequisite for sure, The ACMQ middle layer looks very attractive since I assume DI will be using OTP already. I know about assumptions however! 73 Neal Campbell Abroham Neal Software www.abrohamnealsoftware.com (540) 645 5394 NEW PHONE NUMBER
Amateur Radio: K3NC Blog: http://www.abrohamnealsoftware.com/blog/ DXBase bug reports: email to [email protected] Abroham Neal forums: http:/www.abrohamnealsoftware.com/community/ On Wed, Jun 30, 2010 at 1:52 PM, David McKenzie <[email protected]> wrote: > I think an event/subscription based architecture for actual modules makes a > lot of sense as well, outside the CAT realm. Take for example, a tone > encoder/decoder module. It could connect to the core software, using TCP > and > establishing a secure, authenticated session, if desired. Then it can > subscribe to demodulated audio from the receiver, as well as advertise to > the core that it has configuration attributes, and subscribe to any event > notifications, such as tone on/off. It can then process the demodulated > audio, strip out or insert the tone as necessary, and pass on the data to > the next module. It would obviously also be important to be able to decide > where the module is inserted in the chain. > > On Wed, Jun 30, 2010 at 11:38 AM, Peter G. Viscarola <[email protected] > >wrote: > > > Inline > > > > Sounds like you are interested in source-based messaging in the manner of > > CAN as used in automobiles. Just be aware of the security problems that > will > > crop up. We do have enough processing power that supporting multiple TCP > > sessions and replicating the data probably is easy enough to do and then > we > > can take advantage of existing security protocols. > > > > Well, CAN-bus works down through the hardware level. But the same sort > of > > distributed messaging can be applied, as you said, even with TCP > sessions. > > > > > > Further, it probably makes sense to at least consider making this > protocol > > a "mesh" and not merely "one to many" -- That is, any module can be a > > producer or a consumer of events. It makes the registration and > switching > > more complex, but it allows infinite variety and expandability. > > > > Yes, you are thinking in terms of CAN. Great when you have administrative > > and physical control of all the hardware so you can impose physical > security > > but that won't fly if we want to distribute applications over the > Internet > > without building application-specific gateways. > > > > Depends on what you consider a gateway. Consider that while > communications > > can be done in a mesh, there will almost certainly need to be a central > > registration authority, right? Someplace where producers and consumers > go > > to "discover" each other - Register the events that they provide, and > > discover which events are available for subscription. In other words, a > > directory service. This can serve as the necessary authentication point. > > (So, Provider A registers that he provides events 1, 2, and 3 with > > whatever attributes and characteristics make sense (description, version, > > expected frequency... I don't know, whatever). Provider B registers > the > > provision of events 7 and 8. Now, Consumer X comes along and asks the > > directory service what events are available for subscription, and then > sends > > a request directly to the Providers to register. That registration > > information can include a token provided by the directory service, if > > consumer authentication with each provider is required). > > This is really just a P2P scheme, right? Not unlike bittorrent, for > > example. > > We're sketching in pencil on a cocktail napkin here, which is cool, as > long > > as we all agree that's what we're doing... :-) > > P > > _______________________________________________ > > Flexedge mailing list > > [email protected] > > http://mail.flex-radio.biz/mailman/listinfo/flexedge_flex-radio.biz > > This is the FlexRadio Systems e-mail Reflector called FlexEdge. It is > used > > for posting topics related to SDR software development and > experimentalist > > who are using alpha and beta versions of the software. > > > _______________________________________________ > Flexedge mailing list > [email protected] > http://mail.flex-radio.biz/mailman/listinfo/flexedge_flex-radio.biz > This is the FlexRadio Systems e-mail Reflector called FlexEdge. It is used > for posting topics related to SDR software development and experimentalist > who are using alpha and beta versions of the software. > _______________________________________________ Flexedge mailing list [email protected] http://mail.flex-radio.biz/mailman/listinfo/flexedge_flex-radio.biz This is the FlexRadio Systems e-mail Reflector called FlexEdge. It is used for posting topics related to SDR software development and experimentalist who are using alpha and beta versions of the software.
