URL and 'data:' protocol - was Re: [Commit] ImageTagRegistry and friends

[Thomas E Deweese <th...@kodak.com>]

>>>>> "CJ" == Christophe Jolif <cj...@ilog.fr> writes:

CJ> Thomas, Thomas E Deweese wrote:

>> I was actually planning on using the 'java.protocol.handler.pkgs'
>> system property to register the protocol handler.  This works
>> around the one URLStreamHandler registration issue.  However, you
>> are correct about the Applet issue :(
>> 
>> Well, I _really_ _really_ _really_ hate passing around URL's as
>> Strings.  It's ugly nasty, and leads to lots of replicated code
>> that that tries to analyze this or that piece of the URL.  
>> [...]
>> We can support constructing the 'odd' URLS through the
>> URL(URL context, String spec, URLStreamHandler handler) method
>> which should allow us to use any URLStreamHandler we decide we want
>> with no policy issues (we could also construct our own parallel URL
>> class, but we can't extend URL).
>> 
>> Anyone have comments, better ideas (I hope!).

CJ> I totally agree with you, I really like the idea of using an
CJ> extended protocol on URL to deal with the data protocol instead of
CJ> making our own stuff. 

CJ> However looking one more time at URL class documentation, it looks
CJ> like that we will come up with the same problem by using the
CJ> URL(ctx, spec, handler) ctor because it also throws a security
CJ> exception...

    AAARRRGGG!!!
    
    I don't even want to know why this might be a Security violation,
seems like it should be 100% safe (I mean it's one thing to magically
get someones implementation of a url stream handler, it's another
thing when I provide that handler in the constrcutor).

    Anyway, I guess this pushes us to a parallel URL class.  It's ugly
though since anytime we interface with external libraries that might
take a URL we will have to "do something".  Where I haven't sorted out
what "something" is. :)

    Better ideas? Please!

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org