felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@odoko.co.uk>
Subject Re: URL Handlers service
Date Fri, 04 Nov 2005 09:28:24 GMT
Richard S. Hall wrote:
> [Warning! This will probably be long.]
> 
> Ok, I am on the verge of committing my URL Handlers service
> modifications to Felix. Currently, URL Handlers is broken for Felix and
> this should fix that; it should also add explicit support for using URL
> Handlers with multiple framework instances.
> 
> The approach I took to support multiple framework instances was what I
> outlined before. I created an essentially static URL Handlers service
> implementation. All framework instances wishing to use the URL Handlers
> service register with the static service upon creation. The static
> implementation acts as a multiplexer, routing incoming stream/content
> handler requests to handler services inside the appropriate framework
> instance. This means that bundles inside one framework instance will
> only see handler services from other bundles inside their respective
> framework instance. I have done minor testing and this appears to work,
> but more testing will definitely be necessary.
> 
> The approach I use to route incoming handler requests is to use the
> security class context, which gives me the call stack of classes. I then
> search backwards to find the first class loaded from a bundle and then
> route to the framework that owns that bundle. As an optimization, if
> there is only one framework instance, then I just assume that every
> request should be routed to it.
> 
> I also have a property that allows you to disable the URL Handlers
> service, which means that the URL.setURLStreamHandlerFactory() and
> URLConnection.setContentHandlerFactory() will not get called if the
> service is disabled. However, since this configuration property can be
> set on a per-instance basis, if one instance enables it, then these
> methods will get called. In that case, instances that disable it will
> simply not offer the service to their contained bundles, while instances
> that enable it will.
> 
> There are a few other things that still need to be finished before it is
> completely usable, which are:
> 
>    * Integrate with "bundle:" resource handling.
>    * Deal with built-in handlers.
>    * Implement appropriate security measures.
> 
> Even without these, it is still usable. Once these issues are addressed,
> then full spec compliance for URL Handlers will basically be done. My
> main motivation for now is to deal with built-in handlers properly,
> since I am currently just doing a hard-coded check for "file:", which is
> definitely a hack. The spec says a bit about dealing with built-in
> handlers, so I have to re-read it and see if it enlightens me on this
> topic.
> 
> I will try to get what I have committed next week, if I feel confident
> it won't break a bunch of stuff. :-)

It is great to see you working hard on this. I get the impression that
this was quite a knotty one.

I'd like, however, to ask if it is at all possible for you to do this
kind of development work in a more bite-sized way. If your code comes in
in small increments, you'll find that the community will likely
understand it better, and thus be better equipped to help
maintain/enhance it. Otherwise, it could just end up with us all
deferring to you for maintenance of this code, which wouldn't be ideal.

If you're concerned about breaking something, you can always commit the
code you've done so far to some sandbox in SVN, then use svn move to
move it to the correct resting place once it works.

Consider this approach as a training exercise for the rest of us!

Does this sound reasonable/plausible?

I hope I'm not too off-base suggesting this.

Regards, Upayavira

Mime
View raw message