[Anonymous]

Looking at the infrastructure already provided by poco, it would be sort of cool to be able to implement "standalone" subsystems, that is subsystems that can be run as a different process and still communicate with the host application.
Basically, it looks like this would require abstracting the subsystem class some more to also allow communicating via IPC, i.e. sockets, with other software. Something like this would probably be as useful as the task type that's already provided by poco in order to faciliate multi-threaded programming, because it could easily allow programmers to implement multi-core support on a per-process level, while simultaenously even allowing users to easily distribute their application by running the standalone subsystems on different machines or even platforms.

Logged In: YES
user_id=1148207
Originator: NO

Interesting idea, but unfortunately hard to implement (the IPC part) in a truly generic way. Any volunteers?

Logged In: NO

Agreed, this doesn't sound very straightforward or feasible: you would normally need to do lots of low level stuff to be able to pass/retrieve data to/from other processes (i.e. data marshalling, serialization etc) and this would also require the corresponding functionality in the core library in the first place, which would ultimately mean that you would be re-inventing the wheel: ACE/TAO, while being admittedly a MONSTER, would be a much more appropriate choice for such an effort.

Logged In: YES
user_id=1148207
Originator: NO

We have a Remoting package (see http://appinf.com/poco/wiki/tiki-index.php?page=Remoting) implementing the equivalent of Java RMI or .NET Remoting for C++ (automatic generation of serializer/deserializer code, etc.), including support for SOAP. It's not under the Boost license, though - you can get it by buying a service level agreement from us. So we did re-invent the wheel somehow ;-)

Logged In: NO

I have previously done something very similar to this, using simply CORBA (omniORB: GPL), it's probably easier to use CORBA for such purposes, rather than really start implementing all the required infrastructure from scratch.
Also, you may want to search sourceforge & freshmeat for alternative ORB implementations.

Logged In: NO

there's "MIBA" (MCLLIB), which is very similar to poco in scope, except maybe for poco's emphasis on embedded development. You may want to check out miba: it's scope is really pretty much the same as poco's, but it does already support IPC: http://mcllib.sourceforge.net & http://sourceforge.net/projects/mcllib

Logged In: NO

basically, you seem to be envisioning an ORB (OBJECT REQUEST BROKER: wikipedia) architecture, and indeed serialization & communications would be the key-components here, if CORBA has too much overhead for your purposes, you may simply want to search freshmeat and sourceforge for alternative "ORB" implementations, there are several more light-weight solutions available-however, CORBA being an international standard, surely does have its benefits, too!
If you are interested in implementing something like this yourself for a poco-based app, you may want to look into the C++ "XTL" (exTernalization Template Library), which should help you deal with most of the supported C++ primitives, you could use sockets to take care of the communications part.

Logged In: YES
user_id=1717232
Originator: NO

How about a mix of Notification Queue + IPC Low Level Implementation + Sockets? With this we can generate a complete IPC implementation, just writing the low level part, queue and socket are ready on poco lib.

Logged In: NO

yes, that sound like a feasible idea-however, I'm not sure whether there's any interest in either adding corresponding IPC part to poco, or adding a new dependency (i.e. a lib such as XTL or S11n (mentioned in another RFE here)). Likewise, you would probably first want to make sure that there's any interest in implementing this idea.
If you do check out the C++ liteFAQ, you'll see that most of the requirements of serializing complex C++ data structures (i.e. nested template classes & graph structures) reliably, would already be fulfilled by XTL or S11n.

Also, given that you would normally want to limit unnecessary communications between different processes due to the corresponding overhead, you would probably want to provide some sort of shared inter-process resource pool, which would ensure that required resources can be easily accessed (and possibly pre-cached) without causing unnecessary performance penalties, so that really all of the available IPC-bandwidth could be primarily used for REAL comms.

Logged In: NO

Please note that there's the zeroc/ice project which is open source and provides pretty straight forward facilities to parallelize and distribute your applications from the ground up:

http://www.zeroc.com/ice.html
http://www.zeroc.com/iceVsCorba.html