ParsedURL vs Accept headers

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

Hi all,

   Philipe Le Hegaret was kind enough to submit a sizeable patch to
Batik to enable the proper use of Accept headers and User Agent
headers in Batik.

     http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1937

   The only problem is that the solution while it works cuts a few
corners, like assuming that ParsedURL will only be used to request
Image data.

   So I see two options:

   1) Add a Parallel interface for URLConnection to ParsedURL.  This
      is a fair amount of work, and will result with a similarly ugly
      sort of code as is currently in the patch (I don't like the
      generic setRequestProperty calls).

   2) Try and abstract a few of the important bits out of the URL
      connection class into parameters on ParsedURL construction and
      openStream calls.

   The decision between #1 and #2 is really a decision on how useful
the rest of the URLConnection interface really is (a lot of it looks
like it's in support of the last 50% which is used .5% of the time).

   My leaning is to go with #2 and if down the road we find use for
the full URLConnection interface we could then treat the #2 additions
as convenience methods.  I'm a little uncomfortable with putting
'http-specific' stuff in the otherwise fairly generic ParsedURL
interface, but since the concepts are generic (what the user agent is,
and what the expected/supported data types are) I think I can justify
it.

   Opinions?

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

Re: ParsedURL vs Accept headers

[Thierry Kormann <tk...@ilog.fr>]

On Monday 16 July 2001 18:58, Thomas E Deweese wrote:
> Hi all,
>
>    Philipe Le Hegaret was kind enough to submit a sizeable patch to
> Batik to enable the proper use of Accept headers and User Agent
> headers in Batik.
>
>      http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1937
>
>    The only problem is that the solution while it works cuts a few
> corners, like assuming that ParsedURL will only be used to request
> Image data.
>
>    So I see two options:
>
>    1) Add a Parallel interface for URLConnection to ParsedURL.  This
>       is a fair amount of work, and will result with a similarly ugly
>       sort of code as is currently in the patch (I don't like the
>       generic setRequestProperty calls).
>
>    2) Try and abstract a few of the important bits out of the URL
>       connection class into parameters on ParsedURL construction and
>       openStream calls.
>
>    The decision between #1 and #2 is really a decision on how useful
> the rest of the URLConnection interface really is (a lot of it looks
> like it's in support of the last 50% which is used .5% of the time).
>
>    My leaning is to go with #2 and if down the road we find use for
> the full URLConnection interface we could then treat the #2 additions
> as convenience methods.  I'm a little uncomfortable with putting
> 'http-specific' stuff in the otherwise fairly generic ParsedURL
> interface, but since the concepts are generic (what the user agent is,
> and what the expected/supported data types are) I think I can justify
> it.
>
>    Opinions?

I don't have a strong opinion about that issue.

Thierry.


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