You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Ole Ersoy <ol...@gmail.com> on 2007/04/04 07:41:53 UTC
[DAS OID GENERATION] Things that make you go hmmmm
OK - I was coming up with all this
terrifically long ways of having a unique
OID for DAS created LDAP metadata.
Then a light bulb turned on (And this very rarely happens).
The EPackages that contain SDO Metadata (The metadata for an SDO
model) are already namespaced. It's the same concept
used to namespace elements in an xml document, and SDO uses
this because it has to be able to serialize model instances
to XML.
For instance Maven POM elements live in the namespace:
http://maven.apache.org/POM/4.0.0
Is
http://maven.apache.org/POM/4.0.0
a legal OID value?
If not we could just generate a checksum
of it, or strip out the illegal characters,
and use that as the globally unique
OID.
Then we just use a simple convention
like
checksum + 1 for the Syntax OID branch
checksum + 2 for the AttributeType OID branch
etc etc etc
Sound OK?
Thanks,
- Ole
Re: [DAS OID GENERATION] Things that make you go hmmmm
Posted by Alex Karasulu <ak...@apache.org>.
Hmmmm if you have short terms then this might produce a longer OID string.
Just thinking about the max size of a hashCode value in the number of
digits. I think it's log 10 (2^32-1) which is what 8 or 9? So if the term
is small then this might be larger.
More inline ...
On 4/5/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
>
>
> On 4/5/07, Alex Karasulu <ak...@apache.org> wrote:
> >
> > Good idea Emmanuel. Permit me to extend on this a bit ...
> >
> > Perhaps instead of getting really long OIDs you can use instead compute
> > a hashCode from the suffix and just concat that as the
> > least significant OID term. For example:
> >
> > 1.3.6.1.4.1.18060.0.4.X.2.org.tuscany.das.ldap.config.DASConfig.baseDN
> >
> > Can be the following valid OID if the hashCode for
> > org.tuscany.das.ldap.config.DASConfig.baseDN is 123456:
> >
> > 1.3.6.1.4.1.18060.0.4.X.2.123456
> >
> > WDYT?
>
>
> Well, I thought about it, but it may break the 'worldwide' characteristics
> : you can't guaranty that this hashcode will be unique. But if you just
> split each word, and compute an hashcode for each of them, the odds that you
> break rhis rule is 0 :
>
I don't think so because you've got the PEN prefix. Then the string you're
taking the hashCode() of will have to be unique no? In combination with the
PEN and the hashCode() I think you're safe wrt collisions.
1.3.6.1.4.1.18060.0.4.X.2."org".hashcode()."tuscany".hashcode(). ... etc
>
SNIP
Alex
Re: [DAS OID GENERATION] Things that make you go hmmmm
Posted by Ole Ersoy <ol...@gmail.com>.
I like that idea as well.
I'll get them all in the design guide.
Thanks,
- Ole
Alex Karasulu wrote:
> Good idea Emmanuel. Permit me to extend on this a bit ...
>
> Perhaps instead of getting really long OIDs you can use instead compute
> a hashCode from the suffix and just concat that as the
> least significant OID term. For example:
>
> 1.3.6.1.4.1.18060.0.4.X.2.org.tuscany.das.ldap.config.DASConfig.baseDN
>
> Can be the following valid OID if the hashCode for
> org.tuscany.das.ldap.config.DASConfig.baseDN is 123456:
>
> 1.3.6.1.4.1.18060.0.4.X.2.123456
>
> WDYT?
>
> Alex
>
> On 4/5/07, *Ole Ersoy* <ole.ersoy@gmail.com
> <ma...@gmail.com>> wrote:
>
> Emmanuel,
>
> Bottle of wine...in Amsterdam...Sooooooure :-)
>
> I think using ascii values is a great idea.
> I'll stick it in the design guide.
>
> Thanks,
> - Ole
>
>
>
> Emmanuel Lecharny wrote:
> > Ole, David,
> >
> > when I woke up this morning, under my shower, I had the idea I missed
> > yesturday evening due to the bottle of wine I drunk ... - : why
> don't
> > you use the ascii value of each character to code your OID,
> postfixing
> > your PEN ? Something like :
> >
> 1.3.6.1.4.1.18060.0.4.X.2.org.tuscany.das.ldap.config.DASConfig.baseDN
> > will be transformed to :
> > 1.3.6.1.4.1.18060.0.4.X.2 (the prefix, where X is a number)
> > .111.114.103.46. ... (111 = 'o', 114='r', 103='g', 46 = '.', etc)
> >
> > you will have very long OIDs, but this is not really a problem,
> and thy
> > will be unique worldwilde because the prefix is assigned to your
> > company, and you will have to manage the suffix (it's up to you
> to use
> > correct packages...)
> >
> >
> > On 4/5/07, *David Jencks* <david_jencks@yahoo.com
> <ma...@yahoo.com>
> > <mailto:david_jencks@yahoo.com <ma...@yahoo.com>>>
> wrote:
> >
> > I would prefer to see a solution that mapped java objects to
> existing
> > schemas, and perhaps has a way to generate schemas with oids,
> but it
> > seems to me that autogeneration of something that is supposed
> to be
> > worldwide unique and meaningful may cause more difficulties
> than it
> > solves.
> >
> >
> > The worldwide OID will be enforced through the prefix (and
> management in
> > the project :)
> >
> > For instance you'd need a way to reserve a unique PEN for each
> > installation on which you wanted to run this stuff.
> >
> >
> > That's very true. But if you use ADS in a company, then this
> company
> > should have a PEN (at least in theory: as there are only 28389
> > attributed PEN as of today ...).
> >
> > dunno, I'm kinda a beginner.
> >
> >
> > you should be kidding ;)
> >
> > thanks
> > david jencks
> >
> >
> > Emmanuel
> >
> > --
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com <http://www.iktek.com> < http://www.iktek.com>
>
>
Re: [DAS OID GENERATION] Things that make you go hmmmm
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 4/5/07, Alex Karasulu <ak...@apache.org> wrote:
>
> Good idea Emmanuel. Permit me to extend on this a bit ...
>
> Perhaps instead of getting really long OIDs you can use instead compute a
> hashCode from the suffix and just concat that as the
> least significant OID term. For example:
>
> 1.3.6.1.4.1.18060.0.4.X.2.org.tuscany.das.ldap.config.DASConfig.baseDN
>
> Can be the following valid OID if the hashCode for
> org.tuscany.das.ldap.config.DASConfig.baseDN is 123456:
>
> 1.3.6.1.4.1.18060.0.4.X.2.123456
>
> WDYT?
Well, I thought about it, but it may break the 'worldwide' characteristics :
you can't guaranty that this hashcode will be unique. But if you just split
each word, and compute an hashcode for each of them, the odds that you break
rhis rule is 0 :
1.3.6.1.4.1.18060.0.4.X.2."org".hashcode()."tuscany".hashcode(). ... etc
>
Alex
>
> On 4/5/07, Ole Ersoy <ol...@gmail.com> wrote:
> >
> > Emmanuel,
> >
> > Bottle of wine...in Amsterdam...Sooooooure :-)
> >
> > I think using ascii values is a great idea.
> > I'll stick it in the design guide.
> >
> > Thanks,
> > - Ole
> >
> >
> >
> > Emmanuel Lecharny wrote:
> > > Ole, David,
> > >
> > > when I woke up this morning, under my shower, I had the idea I missed
> > > yesturday evening due to the bottle of wine I drunk ... - : why don't
> > > you use the ascii value of each character to code your OID, postfixing
> >
> > > your PEN ? Something like :
> > > 1.3.6.1.4.1.18060.0.4.X.2.org.tuscany.das.ldap.config.DASConfig.baseDN
> > > will be transformed to :
> > > 1.3.6.1.4.1.18060.0.4.X.2 (the prefix, where X is a number)
> > > .111.114.103.46. ... (111 = 'o', 114='r', 103='g', 46 = '.', etc)
> > >
> > > you will have very long OIDs, but this is not really a problem, and
> > thy
> > > will be unique worldwilde because the prefix is assigned to your
> > > company, and you will have to manage the suffix (it's up to you to use
> >
> > > correct packages...)
> > >
> > >
> > > On 4/5/07, *David Jencks* <david_jencks@yahoo.com
> > > <mailto:david_jencks@yahoo.com >> wrote:
> > >
> > > I would prefer to see a solution that mapped java objects to
> > existing
> > > schemas, and perhaps has a way to generate schemas with oids, but
> > it
> > > seems to me that autogeneration of something that is supposed to
> > be
> > > worldwide unique and meaningful may cause more difficulties than
> > it
> > > solves.
> > >
> > >
> > > The worldwide OID will be enforced through the prefix (and management
> > in
> > > the project :)
> > >
> > > For instance you'd need a way to reserve a unique PEN for each
> > > installation on which you wanted to run this stuff.
> > >
> > >
> > > That's very true. But if you use ADS in a company, then this company
> > > should have a PEN (at least in theory: as there are only 28389
> > > attributed PEN as of today ...).
> > >
> > > dunno, I'm kinda a beginner.
> > >
> > >
> > > you should be kidding ;)
> > >
> > > thanks
> > > david jencks
> > >
> > >
> > > Emmanuel
> > >
> > > --
> > > Cordialement,
> > > Emmanuel Lécharny
> > > www.iktek.com < http://www.iktek.com>
> >
>
>
--
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [DAS OID GENERATION] Things that make you go hmmmm
Posted by Alex Karasulu <ak...@apache.org>.
Good idea Emmanuel. Permit me to extend on this a bit ...
Perhaps instead of getting really long OIDs you can use instead compute a
hashCode from the suffix and just concat that as the
least significant OID term. For example:
1.3.6.1.4.1.18060.0.4.X.2.org.tuscany.das.ldap.config.DASConfig.baseDN
Can be the following valid OID if the hashCode for
org.tuscany.das.ldap.config.DASConfig.baseDN is 123456:
1.3.6.1.4.1.18060.0.4.X.2.123456
WDYT?
Alex
On 4/5/07, Ole Ersoy <ol...@gmail.com> wrote:
>
> Emmanuel,
>
> Bottle of wine...in Amsterdam...Sooooooure :-)
>
> I think using ascii values is a great idea.
> I'll stick it in the design guide.
>
> Thanks,
> - Ole
>
>
>
> Emmanuel Lecharny wrote:
> > Ole, David,
> >
> > when I woke up this morning, under my shower, I had the idea I missed
> > yesturday evening due to the bottle of wine I drunk ... - : why don't
> > you use the ascii value of each character to code your OID, postfixing
> > your PEN ? Something like :
> > 1.3.6.1.4.1.18060.0.4.X.2.org.tuscany.das.ldap.config.DASConfig.baseDN
> > will be transformed to :
> > 1.3.6.1.4.1.18060.0.4.X.2 (the prefix, where X is a number)
> > .111.114.103.46. ... (111 = 'o', 114='r', 103='g', 46 = '.', etc)
> >
> > you will have very long OIDs, but this is not really a problem, and thy
> > will be unique worldwilde because the prefix is assigned to your
> > company, and you will have to manage the suffix (it's up to you to use
> > correct packages...)
> >
> >
> > On 4/5/07, *David Jencks* <david_jencks@yahoo.com
> > <ma...@yahoo.com>> wrote:
> >
> > I would prefer to see a solution that mapped java objects to
> existing
> > schemas, and perhaps has a way to generate schemas with oids, but it
> > seems to me that autogeneration of something that is supposed to be
> > worldwide unique and meaningful may cause more difficulties than it
> > solves.
> >
> >
> > The worldwide OID will be enforced through the prefix (and management in
> > the project :)
> >
> > For instance you'd need a way to reserve a unique PEN for each
> > installation on which you wanted to run this stuff.
> >
> >
> > That's very true. But if you use ADS in a company, then this company
> > should have a PEN (at least in theory: as there are only 28389
> > attributed PEN as of today ...).
> >
> > dunno, I'm kinda a beginner.
> >
> >
> > you should be kidding ;)
> >
> > thanks
> > david jencks
> >
> >
> > Emmanuel
> >
> > --
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com <http://www.iktek.com>
>
Re: [DAS OID GENERATION] Things that make you go hmmmm
Posted by Ole Ersoy <ol...@gmail.com>.
Comments Inline
David Jencks wrote:
> I would prefer to see a solution that mapped java objects to existing
> schemas
This will be supported. The user just maps their SDO Metadata to
LDAP metadata in the configuration file.
The DAS only generates new LDAP metadata when the user wishes to skip
the mapping tasks.
>and perhaps has a way to generate schemas with oids,
For instance suppose I want to store schemas with my own
globally unique OIDs. I just configure the DAS using my
PEN.
The DAS will automatically create the branches and use an ApacheDS
trigger to increment metadata OID numbers, or I could configure
the branches as well in case it is required for
synchronization / replication / etc.
The challenge with respect to the DAS generating OIDs is that
it has to know what the current OID incremental value needs to be.
Hopefully there is a simple LDAP standard way to discover that for
servers that have yet to support triggers. I know Hibernate supports
surrogate key generation, so that would be a good place to look and see
how they did it. Maybe they just scan the table column looking for
the maximum integer, and they start with that. Our OID's are strings
though, so we'd need something a little more sophisticated.
but it
> seems to me that autogeneration of something that is supposed to be
> worldwide unique and meaningful may cause more difficulties than it solves.
>
> For instance you'd need a way to reserve a unique PEN for each
> installation on which you wanted to run this stuff.
Yes - Each Enterprise that wants to run it needs their own PEN, if they
want to guarantee global uniqueness, which they need when they
want to share metadata with other enterprises. So I'll just put
ApacheDS's PEN in as the configuration default, and we can add a note
in the users guide on "Global Uniqueness" requirements.
>
> dunno, I'm kinda a beginner.
>
Good questions. Do the answers sound ok?
> thanks
> david jencks
>
Cheers,
- Ole
>
> On Apr 4, 2007, at 4:22 PM, Ole Ersoy wrote:
>
>> Yes - That's what I was hoping for - A trigger.
>>
>> Because the DAS could add some entries, and then
>> some other client, and then the DAS again.
>> So both clients would have to increment
>> the current OID number.
>>
>> I think it's a lot better to just make the server
>> responsible for this.
>>
>> Thanks,
>> - Ole
>>
>>
>>
>>
>>
>>
>> Emmanuel Lecharny wrote:
>>> Ole Ersoy a écrit :
>>>> Ah - That throws a fork wrench in my current planning.
>>>>
>>>> Can we change the specification so that we can have characters :-)
>>>>
>>>> OK - that brings up a different more serious question then.
>>>> Does ADS have the ability to assign an OID, sort of like
>>>> automatic surrogate key generation in RDBs?
>>>>
>>>> For instance I may wish to store an attributeType with the
>>>> following description:
>>>>
>>>> "org.tuscany.das.ldap.config.DASConfig.baseDN"
>>>>
>>>> Can ApacheDS assign the OID, thus freeing the DAS of that
>>>> responsibility?
>>> Nope... OIDs are supposed to be unique, worldwide ! This may looks
>>> like impossible to manage, but as you have you PEN, you can
>>> workaround this problem. Just store somwhere in the server the
>>> current number, or the last used number. You grab it, do your
>>> homework (insert your objects), and store the incremented number.
>>> Otherwise, it could be interesting to add a trigger in the server to
>>> auto-increment the OID after each insertion in a specific position
>>> (this is something possible : we support triggers)
>>> SO you have options, but we should discuss them.
>>> The best thing you can do is to assume that ADS can assign OIDs,
>>> whatever soltuion we will have to use to support this feature.
>>> Emmanuel
>>> ("If there is no solution, then the problem suddenly vanishes ...")
>
>
Re: [DAS OID GENERATION] Things that make you go hmmmm
Posted by Ole Ersoy <ol...@gmail.com>.
Emmanuel,
Bottle of wine...in Amsterdam...Sooooooure :-)
I think using ascii values is a great idea.
I'll stick it in the design guide.
Thanks,
- Ole
Emmanuel Lecharny wrote:
> Ole, David,
>
> when I woke up this morning, under my shower, I had the idea I missed
> yesturday evening due to the bottle of wine I drunk ... - : why don't
> you use the ascii value of each character to code your OID, postfixing
> your PEN ? Something like :
> 1.3.6.1.4.1.18060.0.4.X.2.org.tuscany.das.ldap.config.DASConfig.baseDN
> will be transformed to :
> 1.3.6.1.4.1.18060.0.4.X.2 (the prefix, where X is a number)
> .111.114.103.46. ... (111 = 'o', 114='r', 103='g', 46 = '.', etc)
>
> you will have very long OIDs, but this is not really a problem, and thy
> will be unique worldwilde because the prefix is assigned to your
> company, and you will have to manage the suffix (it's up to you to use
> correct packages...)
>
>
> On 4/5/07, *David Jencks* <david_jencks@yahoo.com
> <ma...@yahoo.com>> wrote:
>
> I would prefer to see a solution that mapped java objects to existing
> schemas, and perhaps has a way to generate schemas with oids, but it
> seems to me that autogeneration of something that is supposed to be
> worldwide unique and meaningful may cause more difficulties than it
> solves.
>
>
> The worldwide OID will be enforced through the prefix (and management in
> the project :)
>
> For instance you'd need a way to reserve a unique PEN for each
> installation on which you wanted to run this stuff.
>
>
> That's very true. But if you use ADS in a company, then this company
> should have a PEN (at least in theory: as there are only 28389
> attributed PEN as of today ...).
>
> dunno, I'm kinda a beginner.
>
>
> you should be kidding ;)
>
> thanks
> david jencks
>
>
> Emmanuel
>
> --
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com <http://www.iktek.com>
Re: [DAS OID GENERATION] Things that make you go hmmmm
Posted by Emmanuel Lecharny <el...@gmail.com>.
Ole, David,
when I woke up this morning, under my shower, I had the idea I missed
yesturday evening due to the bottle of wine I drunk ... - : why don't you
use the ascii value of each character to code your OID, postfixing your PEN
? Something like :
1.3.6.1.4.1.18060.0.4.X.2.org.tuscany.das.ldap.config.DASConfig.baseDN will
be transformed to :
1.3.6.1.4.1.18060.0.4.X.2 (the prefix, where X is a number) .111.114.103.46.
... (111 = 'o', 114='r', 103='g', 46 = '.', etc)
you will have very long OIDs, but this is not really a problem, and thy will
be unique worldwilde because the prefix is assigned to your company, and you
will have to manage the suffix (it's up to you to use correct packages...)
On 4/5/07, David Jencks <da...@yahoo.com> wrote:
>
> I would prefer to see a solution that mapped java objects to existing
> schemas, and perhaps has a way to generate schemas with oids, but it
> seems to me that autogeneration of something that is supposed to be
> worldwide unique and meaningful may cause more difficulties than it
> solves.
The worldwide OID will be enforced through the prefix (and management in the
project :)
For instance you'd need a way to reserve a unique PEN for each
> installation on which you wanted to run this stuff.
That's very true. But if you use ADS in a company, then this company should
have a PEN (at least in theory: as there are only 28389 attributed PEN as of
today ...).
dunno, I'm kinda a beginner.
you should be kidding ;)
thanks
> david jencks
Emmanuel
--
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [DAS OID GENERATION] Things that make you go hmmmm
Posted by David Jencks <da...@yahoo.com>.
I would prefer to see a solution that mapped java objects to existing
schemas, and perhaps has a way to generate schemas with oids, but it
seems to me that autogeneration of something that is supposed to be
worldwide unique and meaningful may cause more difficulties than it
solves.
For instance you'd need a way to reserve a unique PEN for each
installation on which you wanted to run this stuff.
dunno, I'm kinda a beginner.
thanks
david jencks
On Apr 4, 2007, at 4:22 PM, Ole Ersoy wrote:
> Yes - That's what I was hoping for - A trigger.
>
> Because the DAS could add some entries, and then
> some other client, and then the DAS again.
> So both clients would have to increment
> the current OID number.
>
> I think it's a lot better to just make the server
> responsible for this.
>
> Thanks,
> - Ole
>
>
>
>
>
>
> Emmanuel Lecharny wrote:
>> Ole Ersoy a écrit :
>>> Ah - That throws a fork wrench in my current planning.
>>>
>>> Can we change the specification so that we can have characters :-)
>>>
>>> OK - that brings up a different more serious question then.
>>> Does ADS have the ability to assign an OID, sort of like
>>> automatic surrogate key generation in RDBs?
>>>
>>> For instance I may wish to store an attributeType with the
>>> following description:
>>>
>>> "org.tuscany.das.ldap.config.DASConfig.baseDN"
>>>
>>> Can ApacheDS assign the OID, thus freeing the DAS of that
>>> responsibility?
>> Nope... OIDs are supposed to be unique, worldwide ! This may looks
>> like impossible to manage, but as you have you PEN, you can
>> workaround this problem. Just store somwhere in the server the
>> current number, or the last used number. You grab it, do your
>> homework (insert your objects), and store the incremented number.
>> Otherwise, it could be interesting to add a trigger in the server
>> to auto-increment the OID after each insertion in a specific
>> position (this is something possible : we support triggers)
>> SO you have options, but we should discuss them.
>> The best thing you can do is to assume that ADS can assign OIDs,
>> whatever soltuion we will have to use to support this feature.
>> Emmanuel
>> ("If there is no solution, then the problem suddenly vanishes ...")
Re: [DAS OID GENERATION] Things that make you go hmmmm
Posted by Ole Ersoy <ol...@gmail.com>.
Yes - That's what I was hoping for - A trigger.
Because the DAS could add some entries, and then
some other client, and then the DAS again.
So both clients would have to increment
the current OID number.
I think it's a lot better to just make the server
responsible for this.
Thanks,
- Ole
Emmanuel Lecharny wrote:
> Ole Ersoy a écrit :
>
>> Ah - That throws a fork wrench in my current planning.
>>
>> Can we change the specification so that we can have characters :-)
>>
>> OK - that brings up a different more serious question then.
>> Does ADS have the ability to assign an OID, sort of like
>> automatic surrogate key generation in RDBs?
>>
>> For instance I may wish to store an attributeType with the
>> following description:
>>
>> "org.tuscany.das.ldap.config.DASConfig.baseDN"
>>
>> Can ApacheDS assign the OID, thus freeing the DAS of that responsibility?
>
> Nope... OIDs are supposed to be unique, worldwide ! This may looks like
> impossible to manage, but as you have you PEN, you can workaround this
> problem. Just store somwhere in the server the current number, or the
> last used number. You grab it, do your homework (insert your objects),
> and store the incremented number.
>
> Otherwise, it could be interesting to add a trigger in the server to
> auto-increment the OID after each insertion in a specific position (this
> is something possible : we support triggers)
>
> SO you have options, but we should discuss them.
>
> The best thing you can do is to assume that ADS can assign OIDs,
> whatever soltuion we will have to use to support this feature.
>
> Emmanuel
>
> ("If there is no solution, then the problem suddenly vanishes ...")
>
Re: [DAS OID GENERATION] Things that make you go hmmmm
Posted by Emmanuel Lecharny <el...@gmail.com>.
Ole Ersoy a écrit :
> Ah - That throws a fork wrench in my current planning.
>
> Can we change the specification so that we can have characters :-)
>
> OK - that brings up a different more serious question then.
> Does ADS have the ability to assign an OID, sort of like
> automatic surrogate key generation in RDBs?
>
> For instance I may wish to store an attributeType with the
> following description:
>
> "org.tuscany.das.ldap.config.DASConfig.baseDN"
>
> Can ApacheDS assign the OID, thus freeing the DAS of that responsibility?
Nope... OIDs are supposed to be unique, worldwide ! This may looks like
impossible to manage, but as you have you PEN, you can workaround this
problem. Just store somwhere in the server the current number, or the
last used number. You grab it, do your homework (insert your objects),
and store the incremented number.
Otherwise, it could be interesting to add a trigger in the server to
auto-increment the OID after each insertion in a specific position (this
is something possible : we support triggers)
SO you have options, but we should discuss them.
The best thing you can do is to assume that ADS can assign OIDs,
whatever soltuion we will have to use to support this feature.
Emmanuel
("If there is no solution, then the problem suddenly vanishes ...")
Re: [DAS OID GENERATION] Things that make you go hmmmm
Posted by Ole Ersoy <ol...@gmail.com>.
Ah - That throws a fork wrench in my current planning.
Can we change the specification so that we can have characters :-)
OK - that brings up a different more serious question then.
Does ADS have the ability to assign an OID, sort of like
automatic surrogate key generation in RDBs?
For instance I may wish to store an attributeType with the
following description:
"org.tuscany.das.ldap.config.DASConfig.baseDN"
Can ApacheDS assign the OID, thus freeing the DAS of that responsibility?
Thanks,
- Ole
Emmanuel Lecharny wrote:
> Ole Ersoy a écrit :
>
>> 1.3.6.1.4.1.18060.0.4.X.2.org.tuscany.das.ldap.config.DASConfig.baseDN
>>
>> and for Syntax entries:
>>
>> 1.3.6.1.4.1.18060.0.4.X.0.java.lang.String
>>
>> That works right (I'm assuming the +* at the end of the regex means
>> wildcard...)?
>
> no, this is not good. Only numbers and '.' are allowed ...
>
> Emmanuel
>
>
Re: [DAS OID GENERATION] Things that make you go hmmmm
Posted by Ole Ersoy <ol...@gmail.com>.
Oh - Is
"org.tuscany.das.ldap.config.DASConfig.baseDN"
a legal description for an attributeType, or
do the periods have to be replaced with dashes '-' or something?
Thanks,
- Ole
Emmanuel Lecharny wrote:
> Ole Ersoy a écrit :
>
>> 1.3.6.1.4.1.18060.0.4.X.2.org.tuscany.das.ldap.config.DASConfig.baseDN
>>
>> and for Syntax entries:
>>
>> 1.3.6.1.4.1.18060.0.4.X.0.java.lang.String
>>
>> That works right (I'm assuming the +* at the end of the regex means
>> wildcard...)?
>
> no, this is not good. Only numbers and '.' are allowed ...
>
> Emmanuel
>
>
Re: [DAS OID GENERATION] Things that make you go hmmmm
Posted by Emmanuel Lecharny <el...@gmail.com>.
Ole Ersoy a écrit :
> 1.3.6.1.4.1.18060.0.4.X.2.org.tuscany.das.ldap.config.DASConfig.baseDN
>
> and for Syntax entries:
>
> 1.3.6.1.4.1.18060.0.4.X.0.java.lang.String
>
> That works right (I'm assuming the +* at the end of the regex means
> wildcard...)?
no, this is not good. Only numbers and '.' are allowed ...
Emmanuel
Re: [DAS OID GENERATION] Things that make you go hmmmm
Posted by Ole Ersoy <ol...@gmail.com>.
Hehe :-)
I just glossed over a quick
tutorial right after you sent
me the previous answer.
The Wikipedia link looks a lot better
than my tutorial though.
Anyways, I think in order
to guarantee global uniqueness
we have to go with a scheme like
this for attributeType entries:
1.3.6.1.4.1.18060.0.4.X.2.org.tuscany.das.ldap.config.DASConfig.baseDN
and for Syntax entries:
1.3.6.1.4.1.18060.0.4.X.0.java.lang.String
That works right (I'm assuming the +* at the end of the regex means
wildcard...)?
Thanks,
- Ole
Re: [DAS OID GENERATION] Things that make you go hmmmm
Posted by Emmanuel Lecharny <el...@gmail.com>.
Ole Ersoy a écrit :
>
>> You bet it's not ! OIDs are following this syntax :
>>
>> [0-2]\.[0-9]+(\.([0-9]+)*
>>
> Ok - So
>
> 1.1.1.http://maven.apache.org/POM/4.0.0
>
> is legal?
Man, I think you weren't very serious when you where studying regular
expressions...
I suggest that you first read
http://en.wikipedia.org/wiki/Regular_expression.
I let you as an exercise to check if your proposal fits or not the
regexp I gave you :)
Emmanuel
Re: [DAS OID GENERATION] Things that make you go hmmmm
Posted by Ole Ersoy <ol...@gmail.com>.
Emmanuel Lecharny wrote:
> Is
> http://maven.apache.org/POM/4.0.0
> a legal OID value?
>
>
> You bet it's not ! OIDs are following this syntax :
>
> [0-2]\.[0-9]+(\.([0-9]+)*
>
Ok - So
1.1.1.http://maven.apache.org/POM/4.0.0
is legal?
I think this would probably be most ideal, since
it corresponds closely with the namespace "Convention"
used by the model packages in general.
Thanks,
- Ole
Re: [DAS OID GENERATION] Things that make you go hmmmm
Posted by Emmanuel Lecharny <el...@gmail.com>.
>
> Is
> http://maven.apache.org/POM/4.0.0
> a legal OID value?
You bet it's not ! OIDs are following this syntax :
[0-2]\.[0-9]+(\.([0-9]+)*
If not we could just generate a checksum
> of it, or strip out the illegal characters,
> and use that as the globally unique
> OID.
>
> Then we just use a simple convention
> like
> checksum + 1 for the Syntax OID branch
> checksum + 2 for the AttributeType OID branch
> etc etc etc
>
> Sound OK?
This is OK if checksum are not duplicated.
--
Cordialement,
Emmanuel Lécharny
www.iktek.com