[glue-wg] No audio

[Florido Paganelli]

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


-- 
==================================================
 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
==================================================