directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: [ADS 3.0] Extensions point
Date Fri, 21 Oct 2011 13:12:49 GMT
On Thu, Oct 20, 2011 at 7:59 PM, Emmanuel Lecharny <elecharny@gmail.com>wrote:

> Hi guys,
>
> we discussed a lot about how we should support OSGi and classload some
> extension points.
>
> I would like to look at the problem from the other side : what are the
> existing extension points, what kind of support we would like to offer for
> each of them, and when do we want to offer such a support... So let's start
> here :
>
> API :
> -----
> 1) Schema Objects : mainly the SyntaxCheckers, LdapComparators and
> Normalizers. We would like those elements being loadable even if no OSGi
> container is present, simply using a class.forName() on them.


Just want to add the link you forwarded to me via IM regarding proper use of
class loaders (everyone please make sure to look at the comments):

http://billhiggins.us/blog/2011/02/24/using-reflection-in-osgi/

We should also be able to use their FQCN and even classload the provided
> bytecode, if they are added thorugh an entry.
>
>
+1


> I'm not sure we should provide such an extensibility for 2.0.0, we can most
> certainly do that for the next version
>
>
I think we can do this for 2.0: it seems like a lot but once a few things
are squared away these things speed up dramatically. However if we get
bogged down we can switch to a 3.0 schedule. I think we should be fluid
about this and respond to whatever difficulties we run into.


> 2) Controls, Extended operations : IMO, encoding and decoding operations
> are by far too complex for those who have no knowledge about the way we do
> that. Actually, that mean Kiran and me, maybe Pierre-Arnaud with a bit of
> training. Ok, this sounds really bad, but we also have to consider that we
> are not likely to add new controls or extended operations frequently.
>
>
It's really dangerous to make these kinds of presumptions even if you're
right to a large extent. Because you just never know what itch people really
will need to scratch.

I'm in disagreement about not making this aspect an extension point. I think
it's critical for third parties to be able to use our API and make it
successful. Perhaps we need better tooling support to assist to some degree
in designing extensions and controls or maybe just some script utility. Who
knows what can happen in this area.


> I would say : wait for a future version (2.0.1 or even later).
>
>
I think we already have an extensible solution right now don't we? You can
add your own control no matter how hard it is right now.


> I don't think we have many more extension points in the API
>
>
Yep.


> Server :
> --------
> 1) Interceptors : Make them bundles right away (I think it's already the
> case)
> 2) Authenticator : Bundles too. For 2.0
> 3) Stored Procedures : This is a complex issue. I don't think its ready for
> 2.0 anyway, and we have to discuss seriously about the security implication
> of allowing those guys to be injected in the server...
>

As with anything you need security. If you can inject an interceptor you can
inject an SP. As always this requires thorough auditing of the code and
making sure sandboxing occurs. But this is a huge win for ApacheDS and was
present earlier. Unfortunately this code dried out and was temporarily
removed.


> 4) Partitions : Bundles, for 2.0.
> 5) Am I missing something ?
>
>
Can't think of much at this time but these certainly are the key extension
points in my mind as well.

-- 
Best Regards,
-- Alex

Mime
View raw message