Subject: Re: [Simple] Re: draft-olson-simple-publish-01.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Nov 2002 00:28:12 -0500

inline.

Paul Kyzivat wrote:
 >
 > Sean Olson wrote:
 >
 >> The analogy breaks down in situations that need more persistence of
 >> the stream identifier. If Call-ID where to persist across all
 >> requests, across reboots, and potentially across devices, then it
 >> would be a perfect fit :)
 >
 >
 > Hmm. If that analogy doesn't hold then it would be helpful to have a
 > more complete description of the semantics of a stream. I guess the
 > discussion of section 1.1.4 Publisher Instance is intended to provide
 > this. But it doesn't line up especially well with the definition of
 > Stream in 3.3. Section 3.3 focuses on providing a context within
 > which to process messages in order, while 1.1.4 focuses on distinct
 > publishing instances. From your comments, you suggest that a distinct
 > instance might not always reside on the same device.

Yes. I think the idea is that you might want to, from one device, change 
the state published originally from another. Example would be, you left 
your work PC on, set your status to "working", and when you get home, 
want to change it to "out of the office", but from a different device.

I admit this is going to get complicated with soft-state refreshes, 
since the work PC will presumably continue to refresh the "working" 
status, resulting in an oscillation of the presence state. Thats clearly 
not what you want.

I suppose a better solution would be for the home PC to publish as a 
separate stream, but publish using the same tuple ID that is being used 
by the work PC. The compositor would them somehow know to select the 
tuple from the home PC as higher priority.

In that case, the stream identifier really is playing the same role as 
the call-id in register, or a dialog ID.

So, it seems we have a few options here:

* use a new header, as in the current doc
* use register-like semantics
* have PUBLISH establish a dialog

The current doc dismisses the idea of dialog establishment. But, since 
publications are soft-state, and if you assume a stream is always tied 
to a particular source, a dialog may make a lot of sense. I always 
regretted the "special case" behavior that REGISTER has, and would 
prefer not to propagate it...

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple