Subject: RE: Rethinking scope on publish, was Re: [Simple] PUBLISH: atomicity problem

From: [email-masked]
Date: Wed, 16 Jul 2003 22:07:27 +0300

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, July 16, 2003 1:19 AM
> To: Jonathan Rosenberg
> Cc: Robert Sparks; Niemi Aki (NMP/Helsinki); [email-masked]
> Subject: Re: Rethinking scope on publish, was Re: [Simple] PUBLISH:
> atomicity problem
> 
> 
> I generally like this idea, but maybe it is still too complex.
> 
> Why do we need the Pstream-ID? Simply say each publisher must choose 
> unique tuple ids and leave it at that.
> 
> Regarding how to set up blocking of the ones you don't want, 
> instead of 
> pstream, how about simply having each publisher include its 
> identity in 
> each tuple, as an attribute? This could be filtered out for 
> most users.

tuple is presence specific. I was thinking of a time-stamp type header (for presence, it probably carries the same info as in the time-stamp element). But then Jonathan mentioned deleting a tuple.

Hisham

> 
> 	Paul
> 
> Jonathan Rosenberg wrote:
> > I was about to post a note on agreeing with Aki.  I was 
> also going to 
> > say that we might want the body to also be the atomic unit, 
> so that when 
> > you publish a tuple, the body is an XML fragment for the 
> tuple. Then, it 
> > ocurred to me that we were really far down the complexity 
> ramp here. So, 
> > I thought about what we could do to really back out of this mess 
> > entirely. Here is my idea.
> > 
> > In the beginning, PUBLISH was easy. Each PUA published its 
> own view of 
> > the presence of the presentity. It had no knowledge of 
> other PUA. It 
> > published a complete presence document which represented 
> what it thought 
> > was the full presence of the presentity. Indeed, if there 
> was only one 
> > PUA, it would be the full presence of the presentity. There 
> was no way 
> > for one PUA to overwrite the published data from another. 
> The tuple IDs 
> > didn't need to have cross-PUA scope. No naming conventions 
> or anything. 
> > The compositor could combine these and modify them as it 
> chose. Each 
> > represented a unique and different piece of info about the 
> presentity. A 
> > useful bit of information was this "Pstream-ID", which uniquely 
> > identified the publisher. You can think of the Pstream-ID 
> as a way of 
> > scoping the tuple IDs. Each tuple ID is defined only within 
> the scope of 
> > a Pstream-ID, and each publisher has to have a unique PStream-ID.
> > 
> > It all got complicated when we decided to try and solve a bigger 
> > problem, where PUA could override information about other PUA. That 
> > introduced all kinds of problems. We needed to define the atomic 
> > information of published presence. We need to resolve tuple 
> naming. We 
> > need to worry about this issue about whether a publish has 
> one or more 
> > tuples. We needed to add Etags and If-Modified-Since. We 
> need to worry 
> > about how to figure out what it means for the system to 
> "wait for human 
> > input" in cases where thats not possible. We don't know how 
> to do that yet.
> > 
> > Perhaps we should reconsider whether we want to solve this 
> problem this 
> > way. We have only one use case - when I leave my PC at the 
> office with a 
> > presence state that is wrong, and I want to fix it at home. 
> Well, this 
> > is a nice feature, but is it worth all of the complexity at 
> this point? 
> > There are other ways to deal with it. In fact, I can think of two 
> > alternatives:
> > 
> > 1. You could use the auth policy to simply disable the PC's 
> data from 
> > being placed in notifications, and then publish a separate 
> tuple (i.e., 
> > new piece of independent information) from home. Thats not 
> as good (PC 
> > still refreshes useless state), but its lots simpler than 
> the route we 
> > are on.
> > 
> > 2. You could design a system which only allowed one PUA at 
> a time (akin 
> > to the current model in AIM and YIM). This would manifest itself as 
> > composition policy. The compositor would only use the 
> published document 
> > from the PUA which started publishing most recently - that 
> is, when its 
> > Pstream-ID first appeared. This would also achieve the effect of 
> > disabling the work PC's state when you arrive at home.
> > 
> > 
> > So, to be concrete, I would propose the following:
> > 
> > 
> > 1. Publications carry complete presence documents, representing the 
> > complete presence state of the PUA as far as it knows.
> > 
> > 2. Publishers are identified by a unique PStream-ID, chosen by the 
> > publisher. Copying someone elses Pstream-ID is not allowed, 
> and behavior 
> > in this case is not defined.
> > 
> > 3. There is no ability to overwrite someone elses presence 
> document or 
> > their tuples. Each publisher publishes independent information.
> > 
> > 4. We eliminate the Etag, If-Modified-Since, and atomicity/segment 
> > discussions from Publish.
> > 
> > 5. Compositors can combine the publsihed information 
> however they like. 
> > There is no need to carry through tuple IDs from publication to 
> > notifications.
> > 
> > 6. If you want to block a tuple from getting into a notify, 
> you identify 
> > it by a distinguishing property rather than by tuple ID.
> > 
> > 
> > I believe this approach works nicely for other things too. 
> In the case 
> > of winfo, where you have lots of presence servers, each 
> publishing winfo 
> > for the subscriptions they have, its the same. Each publisher (a 
> > presence server), publishes the complete view of the state 
> - its own 
> > subscriptions. There is no overlap between servers. The compositor 
> > combines these together using a basic policy (combine subscriptions 
> > together that are for the same presentity), and thats it.
> > 
> > I believe it works for mwi too.
> > 
> > I really feel that it is important that we make some 
> simplifications so 
> > that we can make rapid progress here. I don't think we lose 
> much since 
> > we can still get the desired feature; we just get it in a 
> different way.
> > 
> > Thoughts?
> > 
> > -Jonathan R.
> > 
> > Robert Sparks wrote:
> > 
> >> Another way to state this conclusion is that we need to report
> >> success or failure of publishing each atomic element in an 
> independent
> >> fashion. One quick and easy way to achieve that property 
> is to allow
> >> only one atomic element per PUBLISH request.
> >>
> >> I think I heard another way to do this mentioned during 
> the meeting,
> >> where we move reporting the success/failure and any feedback from
> >> the attempt to publish each tuple into the message instead 
> of trying
> >> to capture it all on the status line. For example (I think this is 
> >> what I heard suggested during the meeting), for presence, we could
> >> publish an entire pidf document with several tuples and in 
> the presence
> >> response return an xml document with one element per tuple 
> discussing
> >> the disposition of attempting to publish that tuple.
> >>
> >> Something along the lines of the following (an example to 
> convey the
> >> concept, not a proposal of a syntax)
> >> <publish-results>
> >>   <tuple id="023cfdsf3">
> >>    <success etag="39009sdf" expires="1800"/>
> >>   </tuple>
> >>   <tuple id="990429834">
> >>    <failure/>
> >>   </tuple>
> >> </publish>
> >>
> >> If we were to pursue such an optimization, it might make sense to
> >> look at how to specify a separate etag value in the 
> publish (currently
> >> what we put in an If-Match header) for each atom in the published
> >> document.
> >>
> >> RjS
> >>
> >> On Mon, 2003-07-14 at 19:58, [email-masked] wrote:
> >>
> >>> All,
> >>>
> >>> I'll try to summarize the issues w.r.t. the atomicity of 
> publication 
> >>> here in an attempt to converge the discussion towards a 
> solution to 
> >>> this problem. BTW, I realized that my slides in the 
> SIMPLE session 
> >>> were perhaps not crystal clear on what the problem at hand really 
> >>> was, so my apologies for that.
> >>>
> >>> The core problem is this:
> >>> EPA X sends a PUBLISH with {a, b, c}, after which EPA Y 
> publishes {a, 
> >>> b}. When EPA X tries to refresh its publication of {a, b, c}, the 
> >>> request fails because of a collision, resulting in the EPA X 
> >>> quitting. EPA Y still refreshes its publication of {a, b}, which 
> >>> means {c} expires and goes away. As a result, the 
> publication process 
> >>> has lost information of {c}. This is unacceptable, and with the 
> >>> current versioning mechanism, this can't be remedied by composer 
> >>> policy, for example.
> >>>
> >>> Instead, to get around the above problem, what you send 
> in a PUBLISH 
> >>> needs to match the atomic element of the published 
> information. So 
> >>> each PUBLISH needs to contain a single tuple, because the 
> versioning 
> >>> and expiration all work on the single atomic element level anyway.
> >>>
> >>> This has the apparent drawback in that the PUA has to 
> wait for a 200 
> >>> OK after each PUBLISHed tuple before it can PUBLISH the next one. 
> >>> This occurs upon every refresh cycle, and in systems with high 
> >>> latency, may become a major issue in terms of performance.
> >>>
> >>> Ways to get around this inefficiency:
> >>>     - Remove the restriction on overlapping requests, i.e., allow 
> >>> "pipelining"
> >>>       of PUBLISH requests
> >>>     - Treat the publisher of each tuple as a separate EPA, and 
> >>> therefore not
> >>>       subject to this restriction in the first place (seems like 
> >>> cheating...)
> >>> In conclusion, my proposal is to go with having always a 
> single tuple 
> >>> in a PUBLISH, and allow overlapping PUBLISH requests. To my 
> >>> knowledge, this would fulfill all the related 
> requirements and solve 
> >>> the issue.
> >>>
> >>> Thoughts?
> >>>
> >>> Cheers,
> >>> Aki
> >>>
> >>> _______________________________________________
> >>> Simple mailing list
> >>> [email-masked]
> >>> https://www1.ietf.org/mailman/listinfo/simple
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Simple mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/simple
> >>
> > 
> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Jul 2003 04:18:02 -0400

inline.

[email-masked] wrote:

> 
>> -----Original Message----- From: ext Paul Kyzivat
>> [mailto:[email-masked]] Sent: Wednesday, July 16, 2003 1:19
>> AM To: Jonathan Rosenberg Cc: Robert Sparks; Niemi Aki
>> (NMP/Helsinki); [email-masked] Subject: Re: Rethinking scope on
>> publish, was Re: [Simple] PUBLISH: atomicity problem
>> 
>> 
>> Why do we need the Pstream-ID? Simply say each publisher must
>> choose unique tuple ids and leave it at that.
>> 
>> instead of pstream, how about simply having each publisher
>> include its identity in each tuple, as an attribute? This could
>> be filtered out for most users.
> 
> 
> tuple is presence specific. I was thinking of a time-stamp type
> header (for presence, it probably carries the same info as in the
> time-stamp element). But then Jonathan mentioned deleting a tuple.
> 

My proposal is that deletion of a tuple is done using the 
authorization stuff. Its not a publishing issue.

The ID header is needed for soft-state. If the information being 
published is represented by the content of the PUBLISH request, you 
need an identifier in there to know when a PUBLISH updates/refreshes 
something published previously, or its a new PUA. You cannot rely on 
the From field or credentials for this disambiguation, since I may 
have multiple devices acting on my behalf, all publishing for me, all 
using my credentials and identity information.

I think that pstream-ID was rejected previously because we were ALSO 
using tuple as semantically meaningful identifiers in publication 
processing. I am proposing that this not be the case. The tuple IDs 
only have meaning within the context of the published stream (which is 
pretty much the same semantic they have in a notification stream).

This also allows us to draw a clean line between the process of 
composition, which is data-type specific, and this PUBLISH mechanism, 
which is meant to not be specific to the data type. The "output" of 
the publish mechanism, towards the compositor, is a series of N 
published documents for a resource. The publish processor doesnt know 
what these documents are, or what they represent. It only knows about 
this pstream ID as a way of tagging them, so it can do the soft-state 
management necessary.

Also, consider further that deletion of published documents cannot 
rely on some kind of data-type specific identifier, like a tuple. 
Thats because the PUBLISH message with Expires:0 won't have any 
content. So, you NEED to have an identifier in the header for this to 
work.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Jul 2003 04:18:02 -0400

inline.

-Jonathan R.