Subject: [Simple] collection template

From: Torrey Searle <[email-masked]>
Date: Wed, 18 Sep 2002 12:21:49 +0200

For the inital subscribe to a Template, would it be possible to just 
send the list of people in the collection w/o the actuall state?  IE a 
presence-list of presence elements w/o tuples.  It would seem like an 
appropriate time to get the "collection list" from the server, w/o 
having to guess it from subsquent partial notifies.

Torrey Searle
Indigo Software

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 18 Sep 2002 12:49:57 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> 
> You left out one scenario (the one we should really be 
> comparing to collection as a package), which is the one that 
> uses collection as a template.

No, my first scenario is covering "collection." It doesn't matter
if it's "collection as a package" or "collection as a template."

The purpose of the message to which you replied was to refute
the implied assertion that collections (of any kind) increase
the overall number subscriptions in a system. My message was
*not* attempting to contrast the package approach with the
template approach. Paul is addressing the more general question
about whether collections (of any kind) are worth pursuing, and
I'm trying to make the case that they are.

I should have included the assumption that I was talking about
only one kind of state (e.g. presence). The point I was attempting
to demonstrate does not change as you vary this assumption, though:
the number of subscriptions in the system still increases at
approximately O(n^2) regardless of whether you use collections
(of any kind).

/a

---

From: [email-masked]
Date: Thu, 19 Sep 2002 15:41:45 +0300

...Unless of course the fan out treats all events alike, i.e., subscription for presence.collection.collection results in a SUBSCRIBE for event presence.collection -- the initial notify could still have the same information regardless of the "depth" of the collection.

Thanks,
Aki ;)

> From: ext [email-masked] [mailto:[email-masked]]
> Sent: Thursday, September 19, 2002 3:35 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Simple] collection template
> 
> 
> Hi,
> 
> I still feel uneasy with the template package approach. It 
> should be possible to subscribe to 
> presence.collection.collection and get some sort of 
> notification back. It doesn't seem obvious to me that the 
> collection can work as a template package. 
> 
> Cheers,
> Aki
> 
> > From: ext Paul Kyzivat [mailto:[email-masked]]
> > Sent: Thursday, September 19, 2002 3:51 AM
> > To: Adam Roach
> > Cc: 'Torrey Searle'; [email-masked]
> > Subject: Re: [Simple] collection template
> > 
> > 
> > This suggestion might also address one issue I had. When you 
> > first establish the subscription, or refresh it, or do a 
> > one-time poll for status, the event mechanism requires that a 
> > single notification be returned immediately, containing the 
> > current state of the resource (in this case the contact 
> > list). This is hard to do if the only notifications are 
> > relays of notifications from individual members of the collection.
> > 
> > This idea would begin to solve that problem. But other 
> > problems remain. For instance there is then still no way to 
> > poll for the current state of everything in the collection.
> > 
> > Also, the kind of response you are describing doesn't seem to 
> > fit within the current definition of PIDF. PIDF only permits 
> > you to mention one presentity. You could get creative, and 
> > make a pidf document that uses the address of the collection 
> > as the presentity, and describes all of the collection 
> > members as separate tuples, with the address of the member as 
> > a contact address. Or you could consider extending pidf to 
> > permit inclusion of multiple presentities. I had some 
> > discussions about those kinds of approaches a few months ago, 
> > with Jonathan or Adam I think. But since then things seem to 
> > have gone a different direction.
> > 
> > Without some kind of change I don't see how to make a 
> > collection conform to all the rules of an event package.
> > 
> > 	Paul
> > 
> > Adam Roach wrote:
> > > 
> > > I think that's a really good suggestion. Thanks.
> > > 
> > > /a
> > > 
> > > (nit: s/people/resources/)
> > > 
> > > > From: Torrey Searle [mailto:[email-masked]]
> > > > Sent: Wednesday, September 18, 2002 5:22
> > > > To: [email-masked]
> > > > Subject: [Simple] collection template
> > > >
> > > >

---

From: Adam Roach <[email-masked]>
Date: Fri, 20 Sep 2002 14:16:57 -0500

And that was precisely my intention. In fact, I implied as much
very early in this discussion, with an example message that shows
a subscription to presence.collection.collection.

/a

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, September 19, 2002 7:42
> To: [email-masked]; [email-masked]; [email-masked]
> ...Unless of course the fan out treats all events alike, 
> i.e., subscription for presence.collection.collection results 
> in a SUBSCRIBE for event presence.collection -- the initial 
> notify could still have the same information regardless of 
> the "depth" of the collection.
> 
> Thanks,
> Aki ;)
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 20 Sep 2002 14:20:27 -0500

Of *course* it's interesting. In fact, I included it as an example
in my very first response to this thread, based on the scenario that
Jonathan laid out.

It's a template. It works like a template. "presence.collection"
and "presence.winfo.collection" and "presence.collection.collection"
and "presence.collection.winfo" and "presence.winfo.collection.winfo"
and "presence.collection.collection.winfo" and any other combination
you can think of will all have well-defined semantics. Many of them will
even be useful in some contexts.

/a

> Sent: Thursday, September 19, 2002 7:57
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> Couldn't presence.collection.collection still be interesting? Suppose 
> that I want to have a "presence list" organized into groups, 
> I.E. so I 
> have a collection that subscribse to the Collection of all the people 
> who work at my company (with that list being maintained by the system 
> administrator of the company) and a Family group, and maybe a 
> Group for 
> the members of Community Service I am a member of.  Each collection 
> could be updated w/o me needing to modifiy my collection.
> 
> Any thoughts on this?
> 
> Torrey Searle
> Indigo Software
> 
> [email-masked] a écrit:
> 
> >Hi,
> >

---

From: Adam Roach <[email-masked]>
Date: Fri, 20 Sep 2002 18:23:44 -0500

From: Paul Kyzivat [mailto:[email-masked]]

> Then of course S1 must obtain the credential it uses to act 
> on behalf of C1 somewhow, and S2 must know how to recognize 
> such a credential and decide whether to honor it. This all 
> adds complexity to the use of collections. (Whether they are 
> templates or not.)

The issue of S2 knowing which credentials to trust isn't
inherent in the collections problem. It's something that
arises whenever you use event agents. For presence, it's
the norm.

> Do you see a reasonable way to approach this problem of credentials? 

The permissions problems are congruent to the "Referred-By"
problem -- and we already have people working on that. I expect
to see some output on this topic -- that is, delegation of
credentials for specific tasks -- sometime relatively soon.

/a