directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole.er...@gmail.com>
Subject Re: [DAS] Type's ObjectClass Entry
Date Mon, 23 Apr 2007 01:05:55 GMT
Alex,

Alex Karasulu wrote:
SNIP

> 
> Well if you just check the attributeType of the attribute in the m-may 
> or m-must list you can discern this easily.  It's just an additional 
> lookup and the proper way to go.  Use the type of the attribute to 
> understand what to do with the attribute.  This is how LDAP works.

Yes - I considered this initially.  Me still thinks that using
the "m-ComplexMay" and "m-ComplexMust" is cleaner semantically
and will perform better.  Me thinks
clearer semantics improves the ability of
others to improve the implementation.

SNIP
> No it's not about minor differences.  You're just not comprehending how 
> LDAP schema is to be used.  This is the whole reason why those smart 
> peeps in the ITU and IETF defined a attributeType.  It's something 
> fundamental to LDAP and you're just not using it with your approach.  
> Plus you're mixing a bunch of things together.

Oh - Sorry - Yes we are still defining AttributeType entries,
for "m-ComplexMay" and "m-ComplexMust" ObjectClass attribute.
We are also defining corresponding syntaxes.

> 
>     How about this.  I'll try it out.  If I'm missing something.  I'll
>     get smacked.  Then I'll rework it your way.  I just think it's a simpler
>     design with "m-complexMay" and "m-complexMust".
> 
> 
> Man I'm not interested in smacking you I'm just trying to save you time 
> and give you the answers to your question. 

Hehe - Come on - One Goodd Smack!  :-)  Kidding.  I know - I meant I'll 
get smacked
by the approach, since stuff that does not work, just does not work.

> 
>     Incidentally the SDO JSR takes your approach.  They define everything as
>     a Type.  So no EAttribute and EReference.  They are both just Type.  I
>     still like the additional semantics behind EAttribute and EReference, so
>     I'll give it a shot.  Maybe I'll get burnt, and then you can tell me "I
>     told you so!"  :-)
> 
> That's up to you and I don't care if I am right really.  I'm just 
> responding to your questions.  You don't have to take my advice if you 
> don't want to.  But man are you stubborn :).

Hehe.  Yeah, when I think I have a fairly good grip on why something
should go a certain way I tend to go with it, unless someone presents
a simple verifiable reason why it should be different.  And I do this
with everyone.  I know you are extremely sharp on this stuff.

In this case I think the two approaches are very close.  I think from
ADSs point of view, it will look the same.

I'll just push it through and we'll see what happens.  I think once the 
code is in place it's a lot easier to discuss because we have
concrete sequences to work through, plus I'm going to rewrite all the
design recipes in the Design Guide once everything is in place, so
that I backup why certain things were done a certain way.  This provides
a good context for discussions on improvement on each piece of the DAS.

My original motivation for asking this question was to find out whether
there was something in place already, outside of "m-must" and "m-may" 
that I could use and whether there were any totally clear show stoppers
for "m-complexMay" and "m-complexMust".

Sorry if this absorbed more of it's fair share of everyone's 
consideration.  Originally I thought it was going to be a quicky :-)

Thanks again,
- Ole

Mime
View raw message