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@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@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
-- ================================================== 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@REMOVE_THIShep.lu.se Homepage: http://www.hep.lu.se/staff/paganelli ==================================================