From: soloway@midniteoil.Eng.Sun.COM (Mark Soloway)
Newsgroups: comp.windows.open-look,alt.soft-sys.tooltalk
Subject: Re: tooltalk questions/comments
Date: 23 Dec 1992 02:03:16 GMT
Organization: Sun Microsystems, Inc.
Distribution: world
Reply-To: soloway@midniteoil.Eng.Sun.COM
NNTP-Posting-Host: midniteoil

First of all, this should have been posted to alt.soft-sys.tooltalk.
A full response to Frank Greco's original post can be found in that
newsgroup.  I am cross-posting this to both comp.windows.open-look and
alt.soft-sys.tooltalk...

In article 23079@gasco.com, dlc@gasco.uucp (Darci L. Chapman x5930) writes:
>In article <1992Dec18.225450.8217@shearson.com>, fgreco@shearson.com (Frank Greco) writes:
>
>> I'm in the process of creating my first *real* tooltalk-capable
>> application and have a few questions that perhaps somebody might
>> be able to answer.
[...Text Deleted...]

>> imho, the Tooltalk C language API seems to be cumbersome and 
>> would benefit tremendously from an XView/varargs approach. 
>
>That was my first thought, too! I really, really like the XView API 
>(especially after a year of programming with Motif/Xt...)

Stepping on to my soapbox...

I consider this to be primarily a religious issue, but I will do my
best to list a few pros and cons about both approaches (this is by no means
exhaustive)...

The XView approach:

	Pros:	1) Very few functions to remember and it is obvious what they
		do (xv_create, xv_set, xv_get, xv_destroy).

		2) Across the board general call form:

			xv_func (object_handle, attribute-value list)

		3) Because of ATTR_LIST, it is possible to dynamically construct
		an XView call.

		4) It is not modal.  Each function requires arguments to specify
		everthing it operates on and does not cause set states that affect
		other calls.

		5) Many operations can be done with one function call.
		   (Convenience versus ease of debugging).

	Cons:	1) Virtually no compile-time type checking.

		2) A large set of attributes to remember or look up.

		3) Quite a few features do not fit into the object, attribute-list
		form described above.  You then need to look their functions up.

		4) If many operations are done with one function call, it is
		difficult to determine which operation is causing a problem when
		debugging.  (Convenience versus ease of debugging).

The ToolTalk approach:

	Pros:	1) Full compile-time type checking.

		2) Functions are generally organized in convenient form:

			tt_<object_type>_<attribute>[_create|_set|_add|_destroy]
			   (object_handle[, attribute]);

		3) Most of the functions are not modal.
		
		4) Easy to pin-point a problem to a specific TT API call.
		   (Convenience versus ease of debugging).

	Cons:	1) A large number of functions to remember or look up.

		2) A few functions do not fit into the general form described above.

		3) A few functions are modal and set states that affect the behavior
		of subsequent calls:  i.e.  tt_default_procid_set.  (Not everyone
	 	considers this a "con").

		4) Cannot dynamically construct TT calls.  (It can be faked with
		a large switch statement, but it is not very convenient and does
		allow run-time configuration).

		5) Takes several TT API calls to create a message/pattern
		and set its args.  (Convenience versus ease of debugging).

The intersting thing about what I have listed here is that not all of the pros
and cons are specifically characteristic of the varargs vs. fixed args approach.

The burden of remembering functions versus remembering attribute types is about
the same if the function names and the attribute names are defined in a sensible
way.  IMHO, both TT and XView have done a reasonably good job of this.

The modality of some TT's calls is not a feature of fixed arg APIs.  For example,
all TT calls that require knowledge of the default procid could have had a
procid argument.  This is a design decision that is independent of varargs versus
fixed args.

When looked at objectively, I think the biggest trade-off is compile-time type
checking (can prevent a large variety of bugs) versus run-time dynamic call
construction.  There is also a minor trade-off of the convenience of multiple
operations in one function call versus the ease of debugging (due to being
able to pin-point a failed operation to one function call).

IMHO, I think it is better to inconvenience the programmer a little in order
to create an easier to debug and more maintainable product.  Therefore,
if I do not specifically need dynamic call construction, I would tend to prefer
the fixed arg approach.  Now I'll get off of my soapbox...

>> Also where's the C++ bindings?

I have been creating some public domain C++ TT classes on my own time.
When I feel they are ready (they are implemented, but not well tested),
I will post them to alt.soft-sys.tooltalk.  As far as an official C++
API, I'll pass your interest on to marketing...

>Now a few questions of my own:
>
>Has anyone successfully run the tooltalk demos (located in 
>$OPENWINHOME/shar/src/tooltalk) under OW3.0?? By successfully,
>I mean can you change what is monitored/displayed/broadcasted
>vi ttmon? (Nevermind the 'edit' demo, it's beyond hope).

You need to make sure that ttmon is in the same session as ttsample or
any other TT clients you are interested in monitoring or broadcasting
to.

In the case of the edit demo, you need to make sure the compiled types have
been seen by the ttsession (kill -USR2 if the ttsession is already running).
Also, the edit client needs to be in an execution path that is known
by the ttsession.  The ttsession process inherits the environment of
the process that starts it.

>What is the latest version of ToolTalk available? Programmer's Guide says 1.0,
>the lib is libtt.so.1.1. What are the plans for the next release 
>(not OW 4.0, I hope!! :-)

The libtt.so.1.1 is the ToolTalk 1.0 library.  ToolTalk 1.0.2 is shipped in
OpenWindows in Solaris 2.1.

>Has anyone ever got anything but Null back from tt_message_handler()?? 

tt_message_handler is only set if the message is a request (class is TT_REQUEST)
and it has been handled.

>Any success in dynamically changing the pattern that an application is
>interested in (via tt_pattern_destroy()/tt_pattern_register())? If so,
>what are the steps one goes through?

When you use tt_pattern_destroy the pattern is gone.  You need to create
a new pattern with tt_pattern_create.  On the other hand, you should be
able to call tt_pattern_register and tt_pattern_unregister as often as
you like to register and unregister patterns.  In the case of file-scoped
patterns, you need to call tt_file_join after registering your pattern.
With session-scoped patterns you can call tt_session_join after registering
your pattern or you can use tt_pattern_session_add to specify the session
filed value of the pattern.

>
>I found the Programmer's Guide (1.0) lacking in some very important points:
>
>	- what are valid values of "vtype"?

A vtype can be any NULL-terminated string.  The string that a pattern specifies
as an argument vtype will be used for matching purposes.  The vtype does NOT say
anything about the value of an argument.  For example, if the vtype is "int", the
argument value can still be anything (string, bytes or integer).

The main thing to remember is that vtypes ARE used when determining whether
a particular message matches a pattern.

>	- while all the functions appear to be documented, not nearly enough
>	  is written about how to use all the functions in a cohesive fashion

I agree with your comment...  One of the problems with TT's API is that it has
a lot of functions and most people only need a relatively small subset of the
functions to accomplish their task.  All I can say is that we're working on
better documentation and that we're interested in more input from users...

							- Mark
__________________________________________
\_Mark Soloway (mark.soloway@Eng.Sun.COM)_\
/_Distributed Systems Services (ToolTalk)_/
\__SunSoft (A Sun Microsystems Company)___\

Newsgroups: comp.windows.open-look