[TransWarp] Requirements for the future peak.messaging package

[Phillip J. Eby]

At 07:55 PM 10/4/02 +0200, Ulrich Eck wrote:

>>I do believe that it's possible, using the SpaceRacks idea I described
>>above, to have a common API over all back-end implementations.  I'm not
>>sure it's suitable to your purposes, however, which I'm not entirely
>>clear on.  What are you actually trying to *send* in these messages?
>>Could you describe that part for me?  If you're doing ORB-like things, I
>>don't think what I'm describing is suitable, and you shouldn't even try
>>to align what you're doing with PEAK concepts of co-ordination and
>>messaging.
>
>
>Our application consists of several distributed components (storage-manager,
>workflowservice, utilities, gui) that need to play nicely together in
>realtime (most important for the later planed GUI implementation)
>
>If you want .. it's ORB-like..

Yeah, that's definitely ORB-ish.  I'm not a big believer in N-tier 
distribution when inter-tier communication isn't asynchronous, with the 
exception of database access or other specialized services.  The thing is, 
synchronous services really are more complex to engineer - or at least to 
do them well.  I'd rather "outsource" this sort of thing to specialists (of 
the human variety).


>It's sufficient to have SpaceRacks that support
>realtime-messages when objects are added.

Um, really, the whole SpaceRack concept is oriented towards asynchronous 
messaging and co-ordination, not synchronous communication.  I don't think 
it's what you want.  For N-tier, you want an ORB; use a "real" ORB and thus 
"outsource" its more complex engineering to someone else.  :)  Or base the 
communication front-ends on Twisted or Pyro and just call PEAK objects on 
the back-end.  PEAK isn't going to try to be an ORB or even define ORB 
interfaces; the ORBish things Ty or I need are adequately served by XML-RPC 
via a Zope server, or some other ORB-like protocol-based front-end.