[zeromq-dev] Portability of zeromq

[Michael Powell]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130405/301927ae/attachment.htm>