home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / windows / openloo / 4897 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  8.2 KB
  1. Xref: sparky comp.windows.open-look:4897 alt.soft-sys.tooltalk:60
  2. Path: sparky!uunet!wupost!crcnis1.unl.edu!moe.ksu.ksu.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!male.EBay.Sun.COM!exodus.Eng.Sun.COM!appserv.Eng.Sun.COM!midniteoil!soloway
  3. From: soloway@midniteoil.Eng.Sun.COM (Mark Soloway)
  4. Newsgroups: comp.windows.open-look,alt.soft-sys.tooltalk
  5. Subject: Re: tooltalk questions/comments
  6. Date: 23 Dec 1992 02:03:16 GMT
  7. Organization: Sun Microsystems, Inc.
  8. Lines: 183
  9. Distribution: world
  10. Message-ID: <ljfi74INNh3e@appserv.Eng.Sun.COM>
  11. References: <1992Dec22.015016.23079@gasco.com>
  12. Reply-To: soloway@midniteoil.Eng.Sun.COM
  13. NNTP-Posting-Host: midniteoil
  14.  
  15. First of all, this should have been posted to alt.soft-sys.tooltalk.
  16. A full response to Frank Greco's original post can be found in that
  17. newsgroup.  I am cross-posting this to both comp.windows.open-look and
  18. alt.soft-sys.tooltalk...
  19.  
  20. In article 23079@gasco.com, dlc@gasco.uucp (Darci L. Chapman x5930) writes:
  21. >In article <1992Dec18.225450.8217@shearson.com>, fgreco@shearson.com (Frank Greco) writes:
  22. >
  23. >> I'm in the process of creating my first *real* tooltalk-capable
  24. >> application and have a few questions that perhaps somebody might
  25. >> be able to answer.
  26. [...Text Deleted...]
  27.  
  28. >> imho, the Tooltalk C language API seems to be cumbersome and 
  29. >> would benefit tremendously from an XView/varargs approach. 
  30. >
  31. >That was my first thought, too! I really, really like the XView API 
  32. >(especially after a year of programming with Motif/Xt...)
  33.  
  34. Stepping on to my soapbox...
  35.  
  36. I consider this to be primarily a religious issue, but I will do my
  37. best to list a few pros and cons about both approaches (this is by no means
  38. exhaustive)...
  39.  
  40. The XView approach:
  41.  
  42.     Pros:    1) Very few functions to remember and it is obvious what they
  43.         do (xv_create, xv_set, xv_get, xv_destroy).
  44.  
  45.         2) Across the board general call form:
  46.  
  47.             xv_func (object_handle, attribute-value list)
  48.  
  49.         3) Because of ATTR_LIST, it is possible to dynamically construct
  50.         an XView call.
  51.  
  52.         4) It is not modal.  Each function requires arguments to specify
  53.         everthing it operates on and does not cause set states that affect
  54.         other calls.
  55.  
  56.         5) Many operations can be done with one function call.
  57.            (Convenience versus ease of debugging).
  58.  
  59.     Cons:    1) Virtually no compile-time type checking.
  60.  
  61.         2) A large set of attributes to remember or look up.
  62.  
  63.         3) Quite a few features do not fit into the object, attribute-list
  64.         form described above.  You then need to look their functions up.
  65.  
  66.         4) If many operations are done with one function call, it is
  67.         difficult to determine which operation is causing a problem when
  68.         debugging.  (Convenience versus ease of debugging).
  69.  
  70. The ToolTalk approach:
  71.  
  72.     Pros:    1) Full compile-time type checking.
  73.  
  74.         2) Functions are generally organized in convenient form:
  75.  
  76.             tt_<object_type>_<attribute>[_create|_set|_add|_destroy]
  77.                (object_handle[, attribute]);
  78.  
  79.         3) Most of the functions are not modal.
  80.         
  81.         4) Easy to pin-point a problem to a specific TT API call.
  82.            (Convenience versus ease of debugging).
  83.  
  84.     Cons:    1) A large number of functions to remember or look up.
  85.  
  86.         2) A few functions do not fit into the general form described above.
  87.  
  88.         3) A few functions are modal and set states that affect the behavior
  89.         of subsequent calls:  i.e.  tt_default_procid_set.  (Not everyone
  90.          considers this a "con").
  91.  
  92.         4) Cannot dynamically construct TT calls.  (It can be faked with
  93.         a large switch statement, but it is not very convenient and does
  94.         allow run-time configuration).
  95.  
  96.         5) Takes several TT API calls to create a message/pattern
  97.         and set its args.  (Convenience versus ease of debugging).
  98.  
  99. The intersting thing about what I have listed here is that not all of the pros
  100. and cons are specifically characteristic of the varargs vs. fixed args approach.
  101.  
  102. The burden of remembering functions versus remembering attribute types is about
  103. the same if the function names and the attribute names are defined in a sensible
  104. way.  IMHO, both TT and XView have done a reasonably good job of this.
  105.  
  106. The modality of some TT's calls is not a feature of fixed arg APIs.  For example,
  107. all TT calls that require knowledge of the default procid could have had a
  108. procid argument.  This is a design decision that is independent of varargs versus
  109. fixed args.
  110.  
  111. When looked at objectively, I think the biggest trade-off is compile-time type
  112. checking (can prevent a large variety of bugs) versus run-time dynamic call
  113. construction.  There is also a minor trade-off of the convenience of multiple
  114. operations in one function call versus the ease of debugging (due to being
  115. able to pin-point a failed operation to one function call).
  116.  
  117. IMHO, I think it is better to inconvenience the programmer a little in order
  118. to create an easier to debug and more maintainable product.  Therefore,
  119. if I do not specifically need dynamic call construction, I would tend to prefer
  120. the fixed arg approach.  Now I'll get off of my soapbox...
  121.  
  122. >> Also where's the C++ bindings?
  123.  
  124. I have been creating some public domain C++ TT classes on my own time.
  125. When I feel they are ready (they are implemented, but not well tested),
  126. I will post them to alt.soft-sys.tooltalk.  As far as an official C++
  127. API, I'll pass your interest on to marketing...
  128.  
  129. >Now a few questions of my own:
  130. >
  131. >Has anyone successfully run the tooltalk demos (located in 
  132. >$OPENWINHOME/shar/src/tooltalk) under OW3.0?? By successfully,
  133. >I mean can you change what is monitored/displayed/broadcasted
  134. >vi ttmon? (Nevermind the 'edit' demo, it's beyond hope).
  135.  
  136. You need to make sure that ttmon is in the same session as ttsample or
  137. any other TT clients you are interested in monitoring or broadcasting
  138. to.
  139.  
  140. In the case of the edit demo, you need to make sure the compiled types have
  141. been seen by the ttsession (kill -USR2 if the ttsession is already running).
  142. Also, the edit client needs to be in an execution path that is known
  143. by the ttsession.  The ttsession process inherits the environment of
  144. the process that starts it.
  145.  
  146. >What is the latest version of ToolTalk available? Programmer's Guide says 1.0,
  147. >the lib is libtt.so.1.1. What are the plans for the next release 
  148. >(not OW 4.0, I hope!! :-)
  149.  
  150. The libtt.so.1.1 is the ToolTalk 1.0 library.  ToolTalk 1.0.2 is shipped in
  151. OpenWindows in Solaris 2.1.
  152.  
  153. >Has anyone ever got anything but Null back from tt_message_handler()?? 
  154.  
  155. tt_message_handler is only set if the message is a request (class is TT_REQUEST)
  156. and it has been handled.
  157.  
  158. >Any success in dynamically changing the pattern that an application is
  159. >interested in (via tt_pattern_destroy()/tt_pattern_register())? If so,
  160. >what are the steps one goes through?
  161.  
  162. When you use tt_pattern_destroy the pattern is gone.  You need to create
  163. a new pattern with tt_pattern_create.  On the other hand, you should be
  164. able to call tt_pattern_register and tt_pattern_unregister as often as
  165. you like to register and unregister patterns.  In the case of file-scoped
  166. patterns, you need to call tt_file_join after registering your pattern.
  167. With session-scoped patterns you can call tt_session_join after registering
  168. your pattern or you can use tt_pattern_session_add to specify the session
  169. filed value of the pattern.
  170.  
  171. >
  172. >I found the Programmer's Guide (1.0) lacking in some very important points:
  173. >
  174. >    - what are valid values of "vtype"?
  175.  
  176. A vtype can be any NULL-terminated string.  The string that a pattern specifies
  177. as an argument vtype will be used for matching purposes.  The vtype does NOT say
  178. anything about the value of an argument.  For example, if the vtype is "int", the
  179. argument value can still be anything (string, bytes or integer).
  180.  
  181. The main thing to remember is that vtypes ARE used when determining whether
  182. a particular message matches a pattern.
  183.  
  184. >    - while all the functions appear to be documented, not nearly enough
  185. >      is written about how to use all the functions in a cohesive fashion
  186.  
  187. I agree with your comment...  One of the problems with TT's API is that it has
  188. a lot of functions and most people only need a relatively small subset of the
  189. functions to accomplish their task.  All I can say is that we're working on
  190. better documentation and that we're interested in more input from users...
  191.  
  192.                             - Mark
  193. __________________________________________
  194. \_Mark Soloway (mark.soloway@Eng.Sun.COM)_\
  195. /_Distributed Systems Services (ToolTalk)_/
  196. \__SunSoft (A Sun Microsystems Company)___\
  197.  
  198.