Norbet Reilly wrote:
> Thanks very much for taking the time to address my query! Some
> comments inline...
>
NP
> On 9/7/05, *Alex Karasulu* <aok123@bellsouth.net
> <mailto:aok123@bellsouth.net>> wrote:
>
> Norbet Reilly wrote:
>
>
<snip/>
> > I notice the addition of AddContextPartitionConfiguration in
> ApacheDS
> > 0.9.2, but I'm not sure hwo to configure its use via an ApacheDS
> > configuration file (or even if it is indeed the answer to my
> problems).
>
> Nah this is something else totally. It's for dynamically adding and
> removing partitions after system startup.
>
>
> Ultimately there will be some linkage as the dynamically added
> partition will need to inform the DS core of some of its features, but
> of course that isn't relevant until the pathway for this information
> is known ;-)
>
Yes good point I did not think of that.
> > Failing that the only other approach I can think of is to get the
> > startup infrastructure to create a back-end InitialContext very
> early
> > so that my custom partition is queried for its schema just after the
> > bootstrap schemas are processed, which sounds a very
> experimental path
> > to follow.
>
> Yeah you're not in a very good situation actually. There really
> is no
> clean way to solve your problem. We just need to implement the Schema
> subsystem properly. You interested in giving that a try?
>
>
> I'm working as a permanent employee currently, so I might need to come
> up with a short term solution initially (assuming that is possible).
> Once I've read the RFC more thoroughly and formed of picture in my
> mind of the work required, then I may consider asking my employer for
> permission to work on the schema subsystem. While there is mutual
> benefit, and assuming the amount of work required is not enormous,
> I've got a fairly good chance of a favourable response.
>
> I should also mention that my interested in DS is to act as an
> intermediate proxy between an existing C++ client and a directory,
> where there is a strong focus on avoiding (or at least minimising)
> changes to client. Thinking about it, supporting the RFC 3672 stuff
> would most probably mean zero change to the client.
>
> Do you have any rough idea of a) the design and b) the amount of time
> you guess it would take you to come up with a solution (I'd double it
> at least, given my very limited exposure to the DS codebase/architecture).
>
Well I have not fully thought of it yet. I am busy right now
implementing the subentry RFC (3672). Next I will move on to collective
attributes (3671) to test the functionality in the subentry code. Then
I will work on adding X.501 defined ACIs with some other folks here.
After this I think it's time to attack the schema issues. However
someone can work the schema code in parallel with us after this week
when the subentry code is complete and tested.
> > Note that attempting to refresh the schema via JXplorer never
> seems to
> > have any effect (I imagine that somewhere in the server it is
> assumed
> > that there are only bootstrap schemas).
>
> You guessed right ... schema is static on startup.
>
> >
> > Any guidance would be very much appreciated!
>
> Sorry can't really give you a better way here other than to build out
> the schema subsystem so it can support your needs. This means just
> implementing it properly. There is no other trick we can use at
> the moment.
>
> Alex
>
>
> Thanks again for taking time to answer my query.
Glad to see your interest. Hope to see you contribute one day.
Cheers,
Alex
|