Re: [xdi] Multiplicity questions

[Michael Schwartz <mike@gluu.org>]

To me, the question boils down to when the server returns order results, 
how does it order them. From this perspective, it doesn't matter if the 
values are [1,2,3,4...]  or [10,99,400,500...].

And we certainly don't want to make delete operations have to change the 
values of other nodes in the tree. This would be hugely expensive.

thx,

Mike



On Mon, 2 Jul 2012, Drummond Reed wrote:

> I believe interoperability of multiplicity is going to be one of the keys
> to interoperability of XDI as a whole. That's why it's been such a focus of
> mine.
>
> The question Markus asks is a key one with regard to interoperability: how
> does a client add a new instance to a set of instances?
>
> Markus, what about the pattern of the client asking to set a new instance
> using an XDI variable, and the server setting the i-number of the new
> instance? That way each server can manage the i-number set in the way
> that's optimal for that server and that set.
>
> Mike, when you say, " the values are ordered lowest-->highest, not
> sequentially", what do you mean by "lowest-->highest"?
>
> I think the rule should be only that each instance within the set has a
> unique i-number in the set, not that there is any implicit order at all
> (explicit order can be added with $* statements). However if we are going
> to specify an implicit order, we should be absolutely clear about what that
> rule is.
>
> =Drummond
>
> On Mon, Jul 2, 2012 at 10:39 AM, Michael Schwartz <mike@gluu.org> wrote:
>
> > Markus,
> >
> > I think the plan was to say that the values are ordered lowest-->highest,
> > not sequentially. So there was never any assumption on my part that all
> > integers would be present.
> >
> > thx,
> >
> >
> > Mike
> >
> >
> >
> > On Mon, 2 Jul 2012, Markus Sabadello wrote:
> >
> >  Okay, makes sense to me.
> > > In this case however the spec should at least say that the $!1, $!2, $!3
> > > pattern is just one possible way to do it, and that GUID-style I-Numbers
> > > are also possible.
> > >
> > > And no implementation should rely on the $!1, $!2, $!3 pattern, or we'll
> > > have interoperability problems.
> > >
> > > Markus
> > >
> > > On Mon, Jul 2, 2012 at 7:24 PM, Michael Schwartz <mike@gluu.org> wrote:
> > >
> > >
> > > > Markus,
> > > >
> > > > I think this is a question about convention. I don't think we need any
> > > > proposal in this area.
> > > >
> > > > - Mike
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, 2 Jul 2012, Markus Sabadello wrote:
> > > >
> > > >  Example:
> > > >
> > > > > =markus$*(+email)$!1/!/(data:,****aaa)
> > > > > =markus$*(+email)$!2/!/(data:,****bbb)
> > > > > =markus$*(+email)$!3/!/(data:,****ccc)
> > > > >
> > > > >
> > > > > I was wondering.. If you first delete let's say the $!2 value, and then
> > > > > add
> > > > > a new value, does the $!2 get recycled?
> > > > > Or does the counter always keep going up, i.e. $!4 would be issued, even
> > > > > if
> > > > > $!2 is unused?
> > > > >
> > > > > I think I-Numbers should not be recycled for new values, and new ones
> > > > > should always be issued.
> > > > >
> > > > > So, I think an extra statement should be introduced to remember the
> > > > > I-Number of the last value:
> > > > >
> > > > > =markus$*(+email)/$!/$!3   <-- last I-Number
> > > > >
> > > > > With this statement it gets much easier and more efficient for the
> > > > > server
> > > > > to add a new value of +email.
> > > > >
> > > > > Or perhaps it would be even better to used GUID-style I-Numbers, then
> > > > > the
> > > > > question of increasing the counter becomes obsolete.
> > > > > Or perhaps the spec should not specify this, i.e. you could either use
> > > > > sequential I-Numbers, or GUID-style ones, whatever you prefer.
> > > > >
> > > > > At XDI2 we need this for implementing link contracts and the policy
> > > > > context
> > > > > nodes, which use the multiplicity format.
> > > > >
> > > > > If this looks right, I'll create a Proposal page.
> > > > >
> > > > > Markus
> > > > >
> > > > >
> > > > >  ------------------------------****----------------------------**
> > > > --**---------
> > > > To unsubscribe, e-mail: xdi-unsubscribe@lists.oasis-****open.org<http://open.org>
> > > > <xdi-unsubscribe@**lists.oasis-open.org<xdi-unsubscribe@lists.oasis-open.org>
> > > > >
> > > >
> > > > For additional commands, e-mail: xdi-help@lists.oasis-open.org
> > ------------------------------**------------------------------**---------
> > To unsubscribe, e-mail: xdi-unsubscribe@lists.oasis-**open.org<xdi-unsubscribe@lists.oasis-open.org>
> > For additional commands, e-mail: xdi-help@lists.oasis-open.org