🚀 go-pugleaf

In article <2b06eae7.6ae4@firefox.csc.calpoly.edu> mdubois@firefox.csc.calpoly.edu (Marcel R Dubois) writes:
	[...deleted...]
   experience developing with ToolTalk.  I heard that there are a lot of
   problems with it, so I'd like to know what I'm getting myself into before
   I dive head first into it.

Watch out!  This newsgroup has very low volume and the Sun engineers watch
it closely!  :-)  I think the first releases of TT had some API quirks 
that drove people nuts; I believe these were fixed in a jumbo patch
that went out 3 or 4 months ago.

Things I like about TT:
1.  Simple.  Doesn't try to do anything more than messaging.  Write your
    own C or C++ wrappers.

2.  Small, clean header resources.  Easily incorporated into an app without
    tripling its size, multiply defining TRUE & FALSE, etc.

3.  "Session" scope operates equally well in X or char-cell display
    environments.


Things I don't like:
1.  "Session" and "Local File" scopes work well, but "Network" scoped
    messages require a common NFS mounted file as a transport vehicle.  Oof.

2.  Source code not available so I can't port it to my other machines.
    The excellent XView/UIC/C++/ToolTalk development environment cannot be
    realized on other platforms.


Things they should add:
1.  Some sort of XDR capability.

2.  Guaranteed serializable messages.  The messaging engine will
    automatically assign a sequential serial number to outbound messages
    and receivers will fault if a gap is detected.  The serial number of
    the first message received after registration becomes the initial
    comparison serial number; alternately, you can override with your
    own initialization number.  *Very* useful.

3.  A message building tool ala Devguide.  You know, some sort of GUI 
    thing that facilitates the naming. scoping, and argument declaration
    of messages.  Message args become elements in a structure instead of
    a list.  Hit a button and it generates the sender side and the
    receiver side code.