[glue-wg] No audio

[Laurence]

Hi Florido,

The question is basically flat vs nested,  similar to the XML, JSON 
discussions. As I mentioned in the previous mail, the decision at the 
time was to go with flat, i.e. not to make any assumption about the DIT.

I agree that this seems a little strange, as LDAP is naturally 
hierarchical, but if you have to interoperate with flat XML or JSON 
information, you would will also have an interoperability problem.

So this is more a discussion about flat vs nested. If there was an 
abstract nested model, then the LDAP DIT would naturally follow this.

I have not been following the recent developments but as far as I 
understand, the predominant view is to go for a flat renderings.

Laurence




On 23/09/13 19:50, Florido Paganelli wrote:
> Hi Laurence,
>
> Thanks for your contribution, as I didn't know the "story so far"
>
> On 2013-09-20 16:11, Laurence wrote:> Hi Florido,
>> Just to respond to your argument in light of the comments from Andre, I
>> think that this discussion is irrelevant.
>>
>> When starting the LDAP rendering, it was decided early on that the DIT
>> would not be considered.
>>
>> For WLCG, it was decided that we would not make use of the DIT.
>>
>> The ARC middleware it seems, does make use of a DIT for the reasons that
>> you mention.
>>
>> These are currently implementation choices and creating an
>> interoperability problem (or not according to Maria).
>>
> I see. Differences in implementations due to fuzzy
> specification/specification not targeted for developers lead to an
> "interoperability problem".
>
> I think we wanted to solve such interoperability issues with GLUE2, but
> it's clear I misunderstood all of it. My bad.
>
>> In my view (as a former co-chair of the group who started this process),
>> the LDAP rendering should proceede without the DIT and a separate
>> document created on the DIT if  needed for interoperability of different
>> implementations.
>>
>> Defining a single DIT is only relvant for those who require this, which
>> does not include WLCG. If there are no other implementations that
>> require agreement on the DIT, I would suggest that you make this an ARC
>> specific specification.
>>
> As I said many times, I fail to understand the above for the sake of
> interoperability and performance, but if this is the feeling the group
> shares, I have no other choice than to accept it.
>
> Regards,
> Florido
>
>> Best Regards,
>>
>> Laurence
>>
>>
>>
>>
>>
>> On 19/09/13 16:26, Florido Paganelli wrote:
>>> Hi All, JP
>>>
>>> On 2013-09-18 17:31, JP Navarro wrote:
>>>> On Sep 18, 2013, at 3:02 PM, Maria Alandes Pradillo
>>>> <Maria.Alandes.Pradillo at cern.ch> wrote:
>>>>
>>>>> I wonder whether we can agree on a solution that maintains the
>>>>> current specification and maybe extends it to include Florido´s
>>>>> changes?
>>> I hope so, this is why we are proposing to move the DIT section to some
>>> appendix/example of community implementation.
>>>
>>>> Maintaining compatibility with the current implementation and
>>>> specification is an important goal.
>>>>
>>>> Even if we can do that, there is higher level debate about what
>>>> should be in the specification, for example:
>>>>
>>>> There are BDII/LDAP deployment and configuration designs that are
>>>> *necessary* for infrastructure publishers and operators, but
>>>> *not*visible* to the users of one or multiple interoperable
>>>> information systems.
>>>>
>>>> So the question is "who needs to know what the DIT is" and "who needs
>>>> to know what the insertion points are"?
>>>>
>>>> If the answer is that *only* infrastructure publishers and operators,
>>>> and NOT users, then the DIT doesn't belong in the LDAP rendering
>>>> specification, but in a profile or community practices document.
>>>>
>>> I am not sure what you mean by users here. I consider users both
>>> developers and consumers of information. I didn't know we write OGF
>>> standards only for people who wants to consume information and not to
>>> produce it, this suprises me a bit. I thought OGF was something  like
>>> IEEE actually... if defines standards.
>>>
>>>> I believe this is the key question regarding DITs.
>>>>
>>> I already said on top of this email and in another email that we can put
>>> these "community practices" as a list of examples in the appendix. We
>>> don't need to suggest or mandate a tree in the document, so we get
>>> closer to a final draft.
>>>
>>> Anyhow, since you asked who-benefits-of-what, I just want to argument a
>>> bit about this tree structure again.
>>>
>>> Coming back to my "file in a directory" example, knowing the absolute
>>> path of a file means one can list it directly, doesn't have to run a
>>> find for it. Knowing a *part* of the absolute path also means that one
>>> start your find from that path and not on the entire filesystem, which
>>> also gives you a performance benefit.
>>>
>>> knowing the DIT means knowing EXACTLY where an object is in the tree,
>>> like absolute paths. Knowing part of the dn is equivalent to knowing
>>> part on an absolute path, so it helps reducing search complexity.
>>>
>>> This said, usually one runs generic queries on LDAP and doesn't care
>>> about the dn. Also, Stephen showed in previous slide that the
>>> performance is already very much acceptable for common queries.
>>>
>>> However, it is clear that if a consumer (or user) *knows* the exact dn
>>> of an object, she can retrieve that object in O(1).
>>> If not, she has to run a search, and the search performance depends on
>>> the complexity of the query.
>>>
>>> This is basically why infrastructure publishers and operators based
>>> their implementation on minimal DIT knowledge. It just makes things
>>> easier and faster to code. This is the same reason why we were
>>> advocating some kind of structure in XML.
>>>
>>> As I said thousand times, ldap is a tree-like database, knowing the
>>> structure of the tree is *not needed* but *if you do* then you can query
>>> faster than if you don't. Moreover, you will have a set of databases
>>> structured more or less in the same way, that might even foster
>>> harmonization, interoperability and integration between information
>>> providers/publishers/generators, elevating GLUE2 to some kind of common
>>> datastructure.
>>> It's really as simple as this. But I don't want to start this topic
>>> again. I just wanted to answer to the who-benefits-of-what question.
>>>
>>> Cheers,
>>> Florido
>> _______________________________________________
>> glue-wg mailing list
>> glue-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/glue-wg
>