[glue-wg] No audio

[Andre Merzky]

On Thu, Sep 19, 2013 at 4:26 PM, Florido Paganelli
<florido.paganelli at hep.lu.se> wrote:
>
> On 2013-09-18 17:31, JP Navarro wrote:
>>
>> 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 surprises me a bit. I thought OGF was something  like
> IEEE actually... if defines standards.

I can answer this part I think.

Obviously, OGF defines standard specifications (or, more precisely,
provides a process to interested communities to define standards).
More specifically though, OGF supports the definition of standards
with support the interoperation of distributes infrastructures.

Toward that end, most standards at OGF focus on implementors of
software, but in many cases, this is actually not sufficient to
provide interoperation -- operational objectives, software
configuration, usage policies and security policies are often needed
to go from a compliant implementation to practical, usable
interoperation.

OGF usually encourages to separate those issues -- specifically, we
don't expect that operational issues are part of the software
(interface, protocol, language etc) specifications.  Rather, we
encourage to keep specifications focused on a specific
interoperability problem, and to allow multiple specs and profiles to
be combined for actual interoperable infrastructures.

It seems to me that the GLUE discussions are somewhat related to the
above -- there seems to be consensus on the GLUE-2 model itself, and
on most of the LDAP rendering, but there seems to be contradictory
opinions on what parts of the LDAP rendering are actually operational,
or implied by usage policies.

Sorry for the long blurb -- but what JP tries to attempt is to help to
separate those issues -- and that seems indeed be necessary, in order
to yield a spec which is applicable to the different existing
implementations.


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

This seems sensible, IMHO.  If you want to go beyond the 'example'
status of the DIT, it might very well fit into a community practice
document, or a profile spec (I do not know enough about LDAP to see if
the latter makes sense, technically).


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

Thanks for the clarification!  That indeed sounds terribly useful, and
I agree on the harmonization, interop and integration part.  But also,
it sounds like an optimization, and an operational property.  Both
important of course, no doubt, but, IMHO, very well separable into its
own spec document?

My $0.02,

  Andre.


> 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
> ==================================================
> _______________________________________________
> glue-wg mailing list
> glue-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/glue-wg



-- 
Nothing is really difficult.