🚀 go-pugleaf

In article <2b06eae7.6ae4@firefox.csc.calpoly.edu> mdubois@firefox.csc.calpoly.edu (Marcel R Dubois) writes:
>
>I'm doing a project for a bay area company as a senior project for myself.
>As part of my project I'm suppose to use ToolTalk to tie some tools
>together.  Anyway, I want to know if anybody out there has had any
>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.
>
>Therefore, if anybody out there can help me out.  Please contact me.

    I'm not sure what you mean by "lots of problems with it", but
    it is being used by a variety of groups in a number of companies,
    and it works for what it was designed for.  Basically ToolTalk
    provides an API for designing messages and patterns, and then
    sending and receiving messages based on what patterns a given
    program supports.  You may scope messages and patterns to a given
    file on a specific system, or a ToolTalk session, or a file in
    a session, or both a specific file and a specific session.

    If you could post more on your application specifics you might
    get further input.
--
Robert Allen, rja@sun.com		DISCLAIMER: I said it, not my company.
		    Samuel Addams: Brewer, Patriot.															        "The right to brew beer is the right to be free!" - me

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.

In article <BUZZ.92Nov18095847@lion.bear.com> buzz@bear.com (Buzz Moschetti) writes:

   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.
   
   ...

   Things they should add:

   ...

   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.


How much to people use the "network" scope? Is NFS reliability, "stale file
handle" and other effects a problem? Do other people think that sequential
ordering on messages is important?

I'm just trying to confirm my suspicion that Tooltalk has an easy-to-use and
flexible communication model, but that its distributed abilities could be
better. 

Also, would anyone like to compare Tooltalk with HPs Broadcast Message
Service?

              -- Robert Cooper
--
-- 

In article <BUZZ.92Nov18095847@lion.bear.com> buzz@bear.com (Buzz Moschetti) writes:
>Things I don't like:
>
>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.

    Developers interested in ToolTalk will be interested to note
    that ToolTalk is now available on Sun Sparc, Sun Intel, SGI,
    IBM, and HP platforms.

    A source product has also recently been made available.
--
Robert Allen, rja@sun.com		DISCLAIMER: I said it, not my company.
		    Samuel Addams: Brewer, Patriot.															        "The right to brew beer is the right to be free!" - me

In article <RCBC.92Nov18124128@taurus.cs.cornell.edu> rcbc@taurus.cs.cornell.edu (Robert Cooper) writes:

   How much to people use the "network" scope? Is NFS reliability, "stale file
   handle" and other effects a problem?

Sure they're a problem.  They're a problem if you're not using ToolTalk, so
they remain a problem after you start using ToolTalk.  However, if the file
server is up, so you can get to the file, then you should be able to get
ToolTalk to deliver messages about the file.

   Do other people think that sequential
   ordering on messages is important?

Yes.  ToolTalk uses TCP so ordering of messages can be relied on.  As long
as no explicit request is made to delay or reroute the message (i.e.,
queuing the message or rejecting it), ToolTalk will never deliver a message
from one sender to a receiver after a message sent later from the same
sender to the same receiver.

BTW, when Robert Allen said that ToolTalk is "available" for HP, IBM, and DEC
RISC UNIX platforms, he slightly exaggerated -- it's been announced,
but won't actually ship until later this year.


Rich

--
Rich McAllister (rfm@eng.sun.com)