[glue-wg] No audio

[Laurence]

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).

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.

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