🚀 go-pugleaf

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

>I have been informed by Sun engineering that messages sent with the TT_QUEUE 
>disposition must be of a static type

Right.  I think the idea is that we only queue a message if we have
reason to believe that there exist tools which will dequeue the
message at some time in the future.  Such beliefs are formed from
looking at the static types database.

However, the API indeed lets senders set message disposition, and it
lets patterns have a disposition attribute.  A message's disposition
attribute tells us what lengths we should go to to deliver the message
to the ptype named in its handler_ptype attribute.  A pattern's
disposition attribute merely lets you match against such messages
according to their disposition attribute.

The juxtaposition of these two API calls might indeed imply the
feature you seem to want: senders could set message disposition to
TT_QUEUE, and the messages could be dequeued when a matching dynamic
pattern (of matching disposition?) is registered.  (Of course, it
would be meaningless to set the disposition to TT_START (unless you
set the handler_ptype), because we have no way of knowing what tool to
start in order to cause the registration of the right dynamic pattern.)

Is this what you're looking for?  What are the requirements you'd be
using it to satisfy?

>that is resident in the classing engine

Yes, although static types can alternatively be stored in the "xdr"
database.  (See tt_type_comp(1)).
--
Brian Holtz