Hello, I am responsible for designing and implementing an embedded device running ArchLinux targeting an ARMV5TE architecture ARM.
At first most of our distributed, "event" (or messaging if you will) pub/sub concerns will be on device. I am also anticipating that eventually we will have ecosystem concerns extending potentially well beyond just the device itself, for manufacture-ability, service-ability, a whole host of other-ability concerns, if you will. (No one here believes me yet, but they're failing to learn from present-day lessons we should be learning from well into the future, but I digress.) Anyway, I am evaluating servant-style infrastructure-enabling agents, like CORBA (a distant second, if third, for reasons that are probably well-known to the folks here on this list), ZeroC Ice for its fast, very scalable servant-style architecture, and not ZeroMQ, is not distributed object technology, per se, but with experience writing some low-scale infrastructure-y concerns, I know the effort it takes, and this will definitely get the job done. In the immediate fore-front I am looking at it as for passing event messages between subsystems in a completely transparent, completely loosely coupled way. The nearest neighbor to something even remotely like that in my experience is bbv EventBroker, for pub/sub brokering of event topics, so to speak. I'm sure there are ways to abstract out the adaptation that must occur on either side of the communications pipe (be they IPC, Pipe, TCP, or whatever) in such a way that makes interfacing with something like this easier to handle. In Object Relational Mapping parlance, I think of the Repository pattern, if you will, as a means of abstracting away how core pub/sub type requests must occur. Something analogous to that. Anyway, hopefully that's enough light shed on the sort of things I think we could utilize here. Am open to replies, suggestions, insights. Most importantly, we'll want to cross compile for ARM (specifically ARMV5TE), and we'll also have C# / .NET 4 (potentially) concerns we'll want to deal with, that sort of thing. Regards, Michael Powell
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
