[glue-wg] No audio

[Florido Paganelli]

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
-- 
==================================================
 Florido Paganelli
   ARC Middleware Developer - NorduGrid Collaboration
   System Administrator
 Lund University
 Department of Physics
 Division of Particle Physics
 BOX118
 221 00 Lund
 Office Tel: 046-2220272
 Email: florido.paganelli at REMOVE_THIShep.lu.se
 Homepage: http://www.hep.lu.se/staff/paganelli
==================================================