[TransWarp] Requirements for the future peak.messaging package

[Ulrich Eck]

Hi Phillip,




> Nope; just exploring the territory at this point.  I'd like to have fewer
> objects to manage than JMS does to accomplish these things, but it's not
> yet clear if we will.

like you mentioned in your mail, specifying interfaces would help to start 
working
on these issues ...

>
> One thought that has occurred to me, is that it may be better to
> implement a transactional, Linda-style tuplespace (or Jini-style
> "JavaSpace") API instead of a messaging API as such.  Everything I've
> laid out as requirements can be cleanly accomplished within that concept,
> and our existing implementations of filesystem-and SQL-based queues could
> be extended to such an API in a straightforward manner.  But the model
> allows for much more powerful distributed/multi-process algorithms than a
> pure "messaging" model does.
>

I just had a look at the JavaSpaces Docs and find it an interesting 
alternative
to our Messaging Model.

Due to it's "simple" nature it could be implemented in python very well.
(Thinking of ZODB + Pyro + Interfaces +
 Logic for locking, searching and notification... for a prototype)

What do you think needs to be done, to be able to specify a global 
structure and
interfaces to implement such a _____Space with python and peak ??



Ulrich Eck
------------------------------------------------------------------------
net-labs Systemhaus GmbH
Ebersberger Str. 46
85570 Markt Schwaben
fon:   +49-8121-4747-11
fax:   +49-8121-4747-77
email: ueck at net-labs.de
http://www.net-labs.de