RE: [Geoserver-devel] GZ GML

Geoghegan_Sean · March 9, 2004, 7:44pm

IMO stuff like Gzip should be handled at either the HTTP server level, as Paul mentioned, or by using Servlet Filters. This means Geoserver does not have to handle it directly.

There is a good article on Servlet filters for content compression at http://www.onjava.com/pub/a/onjava/2003/11/19/filters.html

Sean

-----Original Message-----
From: Chris Holmes [mailto:cholmes@anonymised.com]
Sent: Wednesday, 10 March 2004 10:43 AM
To: Paul Ramsey
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] GZ GML

> Regarding gzipped GML, should GeoServer do this at all? This is a
> protocol level thing, the client requests compression if
possible and
> the server compresses if able. You could probably make GeoServer do
> compression just be running it behind a web server that supported
> compression, like Apache with mod_deflate enabled. Why add any
> infrastructure at all to GeoServer, it is an HTTP thing.

Well, I think GeoServer should definitely send gzipped gml if
the client specifically requests it (in the getFeature
request), as this is completely in the scope of the spec, to
request different formats. This way clients who don't know
how to ask for the gzipped stuff in the http header can also get it.

As for doing it automatically, I'm a bit ambivalent. On the
one hand I do sorta agree that it's a lower level compression
that geoserver shouldn't do. But on the other hand geoserver
is a server, and one of the main design goals is to make it
really easy to set up while still being very powerful. I
imagine that a number of users who have some data to share
aren't sys admins who are super experienced at compiling
apache with mod_deflate, let alone setting up apache with a
connector to a servlet container (something I've done once or
twice and definitely found it to be a bitch). Most all
installs of geoserver I've seen are run directly from the
servlet container, so from that perspective I think it makes
sense to do it for them if we can, as I don't believe (I
could be wrong here) that tomcat or resin or any of them do
that sort of compression in their built in web servers. So
yeah, the one thing I'm going to insist with Gabriel rolling
it in is that it's absolutely seamless. Gabriel, could you
start it on a branch or give it a config option similar to
the SPEED strategy, so we can test it out before it just
shows up in geoserver code? I think it should maybe wait
until 1.2.1, at least as a default. Make the option
available in 1.2.0 so we can all sanity check it if we want
to. And even in 1.2.1 I think we should put an option in the
services.xml file (and in the ui) for users to turn it on or off.

Chris

>
> P.
>
>

--

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free
Linux tutorial presented by Daniel Robbins, President and CEO
of GenToo technologies. Learn everything from fundamentals to
system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Gabriel_Roldan1 · March 10, 2004, 4:12pm

Well, I just committed a refactoring of FeatureTypeResponse to deal with a
new output format: GML2.gz

to do that, I needed to separate the execution of the query from the
response preparation in execute().
The apporach was to leave FeatureResponse deal with the execution and make
delegates for encoding to
the desired output format.
Also added getContentEncoding to Response interface, wich returns null or
the content encoding if there are any. GML2FeatureResponseDelegate returns
"gzip" if outputformat was "GML2.gz". This delegate deals with both GML2 and
GML2.gz formats, but the API now allows to add new encoders for other output
formats by just adding a new encoder (implementation of
FeatureResponseDelegate) in FeatureResponseDelegateFactory.

I have tested it almost extensively and I'm getting the same result as
before the change.

Any feedback will be appreciated.

best regards,

gabriel

----- Original Message -----
From: "Geoghegan, Sean" <Sean.Geoghegan@anonymised.com>
To: "'Chris Holmes'" <cholmes@anonymised.com>; "Paul Ramsey"
<pramsey@anonymised.com>
Cc: <geoserver-devel@lists.sourceforge.net>
Sent: Wednesday, March 10, 2004 4:25 AM
Subject: RE: [Geoserver-devel] GZ GML

IMO stuff like Gzip should be handled at either the HTTP server level, as

Paul mentioned, or by using Servlet Filters. This means Geoserver does not
have to handle it directly.

There is a good article on Servlet filters for content compression at

http://www.onjava.com/pub/a/onjava/2003/11/19/filters.html

Sean

> -----Original Message-----
> From: Chris Holmes [mailto:cholmes@anonymised.com]
> Sent: Wednesday, 10 March 2004 10:43 AM
> To: Paul Ramsey
> Cc: geoserver-devel@lists.sourceforge.net
> Subject: Re: [Geoserver-devel] GZ GML
>
> > Regarding gzipped GML, should GeoServer do this at all? This is a
> > protocol level thing, the client requests compression if
> possible and
> > the server compresses if able. You could probably make GeoServer do
> > compression just be running it behind a web server that supported
> > compression, like Apache with mod_deflate enabled. Why add any
> > infrastructure at all to GeoServer, it is an HTTP thing.
>
> Well, I think GeoServer should definitely send gzipped gml if
> the client specifically requests it (in the getFeature
> request), as this is completely in the scope of the spec, to
> request different formats. This way clients who don't know
> how to ask for the gzipped stuff in the http header can also get it.
>
> As for doing it automatically, I'm a bit ambivalent. On the
> one hand I do sorta agree that it's a lower level compression
> that geoserver shouldn't do. But on the other hand geoserver
> is a server, and one of the main design goals is to make it
> really easy to set up while still being very powerful. I
> imagine that a number of users who have some data to share
> aren't sys admins who are super experienced at compiling
> apache with mod_deflate, let alone setting up apache with a
> connector to a servlet container (something I've done once or
> twice and definitely found it to be a bitch). Most all
> installs of geoserver I've seen are run directly from the
> servlet container, so from that perspective I think it makes
> sense to do it for them if we can, as I don't believe (I
> could be wrong here) that tomcat or resin or any of them do
> that sort of compression in their built in web servers. So
> yeah, the one thing I'm going to insist with Gabriel rolling
> it in is that it's absolutely seamless. Gabriel, could you
> start it on a branch or give it a config option similar to
> the SPEED strategy, so we can test it out before it just
> shows up in geoserver code? I think it should maybe wait
> until 1.2.1, at least as a default. Make the option
> available in 1.2.0 so we can all sanity check it if we want
> to. And even in 1.2.1 I think we should put an option in the
> services.xml file (and in the ui) for users to turn it on or off.
>
> Chris
>
>
>
> >
> > P.
> >
> >
>
> --
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials Free
> Linux tutorial presented by Daniel Robbins, President and CEO
> of GenToo technologies. Learn everything from fundamentals to
> system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Chris_Holmes1 · March 10, 2004, 7:49pm

Hmm.. I really liked the filter idea, having that logic completely
outside of GeoServer. But I do think having the GML2.gz option directly
available to the client is pretty esential, as I don't know that all
clients will know to request it. I've seen other wfs's that make gml2.gz
and gml2.zip available, so I think that's pretty normal to do. And then I
feel like if we've got the logic in geoserver already then we might as
well just do the automatic detection there, or else we'd be replicating
the work of gzipping.

Gabriel, next time you do a change of this sort, that people haven't
necessarily decided on, and that's right before a release, could you put
it on a branch? I think that we should start working on branches for most
any new feature - only bug fixes should routinely go on head. This will
allow us to get releases out more often - after 1.2.0 I'd like to get
minor releases out every 2-4 weeks, for most any little improvement. If
we're always waiting for someone to finish up, and are worried about
testing then that's more difficult to do.

Chris

On Thu, 11 Mar 2004, Gabriel Roldán wrote:

Well, I just committed a refactoring of FeatureTypeResponse to deal with a
new output format: GML2.gz

to do that, I needed to separate the execution of the query from the
response preparation in execute().
The apporach was to leave FeatureResponse deal with the execution and make
delegates for encoding to
the desired output format.
Also added getContentEncoding to Response interface, wich returns null or
the content encoding if there are any. GML2FeatureResponseDelegate returns
"gzip" if outputformat was "GML2.gz". This delegate deals with both GML2 and
GML2.gz formats, but the API now allows to add new encoders for other output
formats by just adding a new encoder (implementation of
FeatureResponseDelegate) in FeatureResponseDelegateFactory.

I have tested it almost extensively and I'm getting the same result as
before the change.

Any feedback will be appreciated.

best regards,

gabriel

----- Original Message -----
From: "Geoghegan, Sean" <Sean.Geoghegan@anonymised.com>
To: "'Chris Holmes'" <cholmes@anonymised.com>; "Paul Ramsey"
<pramsey@anonymised.com>
Cc: <geoserver-devel@lists.sourceforge.net>
Sent: Wednesday, March 10, 2004 4:25 AM
Subject: RE: [Geoserver-devel] GZ GML

> IMO stuff like Gzip should be handled at either the HTTP server level, as
Paul mentioned, or by using Servlet Filters. This means Geoserver does not
have to handle it directly.
>
> There is a good article on Servlet filters for content compression at
http://www.onjava.com/pub/a/onjava/2003/11/19/filters.html
>
> Sean
>
> > -----Original Message-----
> > From: Chris Holmes [mailto:cholmes@anonymised.com]
> > Sent: Wednesday, 10 March 2004 10:43 AM
> > To: Paul Ramsey
> > Cc: geoserver-devel@lists.sourceforge.net
> > Subject: Re: [Geoserver-devel] GZ GML
> >
> > > Regarding gzipped GML, should GeoServer do this at all? This is a
> > > protocol level thing, the client requests compression if
> > possible and
> > > the server compresses if able. You could probably make GeoServer do
> > > compression just be running it behind a web server that supported
> > > compression, like Apache with mod_deflate enabled. Why add any
> > > infrastructure at all to GeoServer, it is an HTTP thing.
> >
> > Well, I think GeoServer should definitely send gzipped gml if
> > the client specifically requests it (in the getFeature
> > request), as this is completely in the scope of the spec, to
> > request different formats. This way clients who don't know
> > how to ask for the gzipped stuff in the http header can also get it.
> >
> > As for doing it automatically, I'm a bit ambivalent. On the
> > one hand I do sorta agree that it's a lower level compression
> > that geoserver shouldn't do. But on the other hand geoserver
> > is a server, and one of the main design goals is to make it
> > really easy to set up while still being very powerful. I
> > imagine that a number of users who have some data to share
> > aren't sys admins who are super experienced at compiling
> > apache with mod_deflate, let alone setting up apache with a
> > connector to a servlet container (something I've done once or
> > twice and definitely found it to be a bitch). Most all
> > installs of geoserver I've seen are run directly from the
> > servlet container, so from that perspective I think it makes
> > sense to do it for them if we can, as I don't believe (I
> > could be wrong here) that tomcat or resin or any of them do
> > that sort of compression in their built in web servers. So
> > yeah, the one thing I'm going to insist with Gabriel rolling
> > it in is that it's absolutely seamless. Gabriel, could you
> > start it on a branch or give it a config option similar to
> > the SPEED strategy, so we can test it out before it just
> > shows up in geoserver code? I think it should maybe wait
> > until 1.2.1, at least as a default. Make the option
> > available in 1.2.0 so we can all sanity check it if we want
> > to. And even in 1.2.1 I think we should put an option in the
> > services.xml file (and in the ui) for users to turn it on or off.
> >
> > Chris
> >
> >
> >
> > >
> > > P.
> > >
> > >
> >
> > --
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials Free
> > Linux tutorial presented by Daniel Robbins, President and CEO
> > of GenToo technologies. Learn everything from fundamentals to
> > system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Geoserver-devel mailing list
> > Geoserver-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--

Gabriel_Roldan1 · March 11, 2004, 2:34am

oops! will use branches, sorry

----- Original Message -----
From: "Chris Holmes" <cholmes@anonymised.com>
To: "Gabriel Roldán" <gabriel.roldan@anonymised.com>
Cc: "Geoghegan, Sean" <Sean.Geoghegan@anonymised.com>; "Paul Ramsey"
<pramsey@anonymised.com>; <geoserver-devel@lists.sourceforge.net>
Sent: Thursday, March 11, 2004 4:38 AM
Subject: Re: [Geoserver-devel] GZ GML

Hmm.. I really liked the filter idea, having that logic completely
outside of GeoServer. But I do think having the GML2.gz option directly
available to the client is pretty esential, as I don't know that all
clients will know to request it. I've seen other wfs's that make gml2.gz
and gml2.zip available, so I think that's pretty normal to do. And then I
feel like if we've got the logic in geoserver already then we might as
well just do the automatic detection there, or else we'd be replicating
the work of gzipping.

Gabriel, next time you do a change of this sort, that people haven't
necessarily decided on, and that's right before a release, could you put
it on a branch? I think that we should start working on branches for most
any new feature - only bug fixes should routinely go on head. This will
allow us to get releases out more often - after 1.2.0 I'd like to get
minor releases out every 2-4 weeks, for most any little improvement. If
we're always waiting for someone to finish up, and are worried about
testing then that's more difficult to do.

Chris

On Thu, 11 Mar 2004, Gabriel Roldán wrote:

> Well, I just committed a refactoring of FeatureTypeResponse to deal with

a

> new output format: GML2.gz
>
> to do that, I needed to separate the execution of the query from the
> response preparation in execute().
> The apporach was to leave FeatureResponse deal with the execution and

make

> delegates for encoding to
> the desired output format.
> Also added getContentEncoding to Response interface, wich returns null

or

> the content encoding if there are any. GML2FeatureResponseDelegate

returns

> "gzip" if outputformat was "GML2.gz". This delegate deals with both GML2

and

> GML2.gz formats, but the API now allows to add new encoders for other

output

> formats by just adding a new encoder (implementation of
> FeatureResponseDelegate) in FeatureResponseDelegateFactory.
>
> I have tested it almost extensively and I'm getting the same result as
> before the change.
>
> Any feedback will be appreciated.
>
> best regards,
>
> gabriel
>
> ----- Original Message -----
> From: "Geoghegan, Sean" <Sean.Geoghegan@anonymised.com>
> To: "'Chris Holmes'" <cholmes@anonymised.com>; "Paul Ramsey"
> <pramsey@anonymised.com>
> Cc: <geoserver-devel@lists.sourceforge.net>
> Sent: Wednesday, March 10, 2004 4:25 AM
> Subject: RE: [Geoserver-devel] GZ GML
>
>
> > IMO stuff like Gzip should be handled at either the HTTP server level,

as

> Paul mentioned, or by using Servlet Filters. This means Geoserver does

not

> have to handle it directly.
> >
> > There is a good article on Servlet filters for content compression at
> http://www.onjava.com/pub/a/onjava/2003/11/19/filters.html
> >
> > Sean
> >
> > > -----Original Message-----
> > > From: Chris Holmes [mailto:cholmes@anonymised.com]
> > > Sent: Wednesday, 10 March 2004 10:43 AM
> > > To: Paul Ramsey
> > > Cc: geoserver-devel@lists.sourceforge.net
> > > Subject: Re: [Geoserver-devel] GZ GML
> > >
> > > > Regarding gzipped GML, should GeoServer do this at all? This is a
> > > > protocol level thing, the client requests compression if
> > > possible and
> > > > the server compresses if able. You could probably make GeoServer

do

> > > > compression just be running it behind a web server that supported
> > > > compression, like Apache with mod_deflate enabled. Why add any
> > > > infrastructure at all to GeoServer, it is an HTTP thing.
> > >
> > > Well, I think GeoServer should definitely send gzipped gml if
> > > the client specifically requests it (in the getFeature
> > > request), as this is completely in the scope of the spec, to
> > > request different formats. This way clients who don't know
> > > how to ask for the gzipped stuff in the http header can also get it.
> > >
> > > As for doing it automatically, I'm a bit ambivalent. On the
> > > one hand I do sorta agree that it's a lower level compression
> > > that geoserver shouldn't do. But on the other hand geoserver
> > > is a server, and one of the main design goals is to make it
> > > really easy to set up while still being very powerful. I
> > > imagine that a number of users who have some data to share
> > > aren't sys admins who are super experienced at compiling
> > > apache with mod_deflate, let alone setting up apache with a
> > > connector to a servlet container (something I've done once or
> > > twice and definitely found it to be a bitch). Most all
> > > installs of geoserver I've seen are run directly from the
> > > servlet container, so from that perspective I think it makes
> > > sense to do it for them if we can, as I don't believe (I
> > > could be wrong here) that tomcat or resin or any of them do
> > > that sort of compression in their built in web servers. So
> > > yeah, the one thing I'm going to insist with Gabriel rolling
> > > it in is that it's absolutely seamless. Gabriel, could you
> > > start it on a branch or give it a config option similar to
> > > the SPEED strategy, so we can test it out before it just
> > > shows up in geoserver code? I think it should maybe wait
> > > until 1.2.1, at least as a default. Make the option
> > > available in 1.2.0 so we can all sanity check it if we want
> > > to. And even in 1.2.1 I think we should put an option in the
> > > services.xml file (and in the ui) for users to turn it on or off.
> > >
> > > Chris
> > >
> > >
> > >
> > > >
> > > > P.
> > > >
> > > >
> > >
> > > --
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by: IBM Linux Tutorials Free
> > > Linux tutorial presented by Daniel Robbins, President and CEO
> > > of GenToo technologies. Learn everything from fundamentals to
> > > system
> > >

administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

> > > _______________________________________________
> > > Geoserver-devel mailing list
> > > Geoserver-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> > >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Geoserver-devel mailing list
> > Geoserver-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>

--

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Chris_Holmes1 · March 11, 2004, 8:53pm

The gz stuff looks good, though we might think about changing one thing.
I sorta feel that if the user requests GML2.gz in his request then the
mime type should be .gz (there's a gzip mime type, right?). I don't think
I so much like the behavior of a browser automatically trying to display
it. I sometimes test huge datasets to see how geoserver holds up, and I
always had to use my little java utilities as mozilla trying to display 10
megs of xml does not lead to a happy mozilla. So I was excited that for
big datasets I could just use the gml2.gz - but with the mime type the
same the browser just displays it. If the mime type was gzip I _think_
mozilla would then give me the option to save it... What do others think
about this? It shouldn't be super difficult to change, no?

<anal rant>
Also could you _please_ format your source code to follow the geoserver
conventions? And could you _please_, _please_
do more javadocing? I let you get away with it more the last time, since
you were on super tight deadlines and were working your ass off. Yes, I
know these are both pretty anal requests, but I feel it's really important
for a collaborative project. I definitely had a little trouble figuring
out what was new and what was old in your re-written stuff. There are
definitions for jalopy in the documents section, which will format your
code exactly as we want it. And do you refractions guys have formatting
definitions for eclipse for GeoServer? And my last anal request is no .*
imports. It's much easier to figure out how to find the classes if they
are all laid out at the top. Eclipse will automatically do this for you -
and I'm sure there are other tools. </anal rant>

Chris

On Thu, 11 Mar 2004, Gabriel Roldán wrote:

oops! will use branches, sorry

----- Original Message -----
From: "Chris Holmes" <cholmes@anonymised.com>
To: "Gabriel Roldán" <gabriel.roldan@anonymised.com>
Cc: "Geoghegan, Sean" <Sean.Geoghegan@anonymised.com>; "Paul Ramsey"
<pramsey@anonymised.com>; <geoserver-devel@lists.sourceforge.net>
Sent: Thursday, March 11, 2004 4:38 AM
Subject: Re: [Geoserver-devel] GZ GML

> Hmm.. I really liked the filter idea, having that logic completely
> outside of GeoServer. But I do think having the GML2.gz option directly
> available to the client is pretty esential, as I don't know that all
> clients will know to request it. I've seen other wfs's that make gml2.gz
> and gml2.zip available, so I think that's pretty normal to do. And then I
> feel like if we've got the logic in geoserver already then we might as
> well just do the automatic detection there, or else we'd be replicating
> the work of gzipping.
>
> Gabriel, next time you do a change of this sort, that people haven't
> necessarily decided on, and that's right before a release, could you put
> it on a branch? I think that we should start working on branches for most
> any new feature - only bug fixes should routinely go on head. This will
> allow us to get releases out more often - after 1.2.0 I'd like to get
> minor releases out every 2-4 weeks, for most any little improvement. If
> we're always waiting for someone to finish up, and are worried about
> testing then that's more difficult to do.
>
> Chris
>
> On Thu, 11 Mar 2004, Gabriel Roldán wrote:
>
> > Well, I just committed a refactoring of FeatureTypeResponse to deal with
a
> > new output format: GML2.gz
> >
> > to do that, I needed to separate the execution of the query from the
> > response preparation in execute().
> > The apporach was to leave FeatureResponse deal with the execution and
make
> > delegates for encoding to
> > the desired output format.
> > Also added getContentEncoding to Response interface, wich returns null
or
> > the content encoding if there are any. GML2FeatureResponseDelegate
returns
> > "gzip" if outputformat was "GML2.gz". This delegate deals with both GML2
and
> > GML2.gz formats, but the API now allows to add new encoders for other
output
> > formats by just adding a new encoder (implementation of
> > FeatureResponseDelegate) in FeatureResponseDelegateFactory.
> >
> > I have tested it almost extensively and I'm getting the same result as
> > before the change.
> >
> > Any feedback will be appreciated.
> >
> > best regards,
> >
> > gabriel
> >
> > ----- Original Message -----
> > From: "Geoghegan, Sean" <Sean.Geoghegan@anonymised.com>
> > To: "'Chris Holmes'" <cholmes@anonymised.com>; "Paul Ramsey"
> > <pramsey@anonymised.com>
> > Cc: <geoserver-devel@lists.sourceforge.net>
> > Sent: Wednesday, March 10, 2004 4:25 AM
> > Subject: RE: [Geoserver-devel] GZ GML
> >
> >
> > > IMO stuff like Gzip should be handled at either the HTTP server level,
as
> > Paul mentioned, or by using Servlet Filters. This means Geoserver does
not
> > have to handle it directly.
> > >
> > > There is a good article on Servlet filters for content compression at
> > http://www.onjava.com/pub/a/onjava/2003/11/19/filters.html
> > >
> > > Sean
> > >
> > > > -----Original Message-----
> > > > From: Chris Holmes [mailto:cholmes@anonymised.com]
> > > > Sent: Wednesday, 10 March 2004 10:43 AM
> > > > To: Paul Ramsey
> > > > Cc: geoserver-devel@lists.sourceforge.net
> > > > Subject: Re: [Geoserver-devel] GZ GML
> > > >
> > > > > Regarding gzipped GML, should GeoServer do this at all? This is a
> > > > > protocol level thing, the client requests compression if
> > > > possible and
> > > > > the server compresses if able. You could probably make GeoServer
do
> > > > > compression just be running it behind a web server that supported
> > > > > compression, like Apache with mod_deflate enabled. Why add any
> > > > > infrastructure at all to GeoServer, it is an HTTP thing.
> > > >
> > > > Well, I think GeoServer should definitely send gzipped gml if
> > > > the client specifically requests it (in the getFeature
> > > > request), as this is completely in the scope of the spec, to
> > > > request different formats. This way clients who don't know
> > > > how to ask for the gzipped stuff in the http header can also get it.
> > > >
> > > > As for doing it automatically, I'm a bit ambivalent. On the
> > > > one hand I do sorta agree that it's a lower level compression
> > > > that geoserver shouldn't do. But on the other hand geoserver
> > > > is a server, and one of the main design goals is to make it
> > > > really easy to set up while still being very powerful. I
> > > > imagine that a number of users who have some data to share
> > > > aren't sys admins who are super experienced at compiling
> > > > apache with mod_deflate, let alone setting up apache with a
> > > > connector to a servlet container (something I've done once or
> > > > twice and definitely found it to be a bitch). Most all
> > > > installs of geoserver I've seen are run directly from the
> > > > servlet container, so from that perspective I think it makes
> > > > sense to do it for them if we can, as I don't believe (I
> > > > could be wrong here) that tomcat or resin or any of them do
> > > > that sort of compression in their built in web servers. So
> > > > yeah, the one thing I'm going to insist with Gabriel rolling
> > > > it in is that it's absolutely seamless. Gabriel, could you
> > > > start it on a branch or give it a config option similar to
> > > > the SPEED strategy, so we can test it out before it just
> > > > shows up in geoserver code? I think it should maybe wait
> > > > until 1.2.1, at least as a default. Make the option
> > > > available in 1.2.0 so we can all sanity check it if we want
> > > > to. And even in 1.2.1 I think we should put an option in the
> > > > services.xml file (and in the ui) for users to turn it on or off.
> > > >
> > > > Chris
> > > >
> > > >
> > > >
> > > > >
> > > > > P.
> > > > >
> > > > >
> > > >
> > > > --
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.Net email is sponsored by: IBM Linux Tutorials Free
> > > > Linux tutorial presented by Daniel Robbins, President and CEO
> > > > of GenToo technologies. Learn everything from fundamentals to
> > > > system
> > > >
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > > > _______________________________________________
> > > > Geoserver-devel mailing list
> > > > Geoserver-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> > > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by: IBM Linux Tutorials
> > > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > > GenToo technologies. Learn everything from fundamentals to system
> > > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > > _______________________________________________
> > > Geoserver-devel mailing list
> > > Geoserver-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Geoserver-devel mailing list
> > Geoserver-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >
>
> --
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--

David_Zwiers1 · March 15, 2004, 2:12pm

Gabriel: You broke the application.

1 | REQUEST
CUSTOM | A valid document | A NON valid document | AND |
- Mon Mar 15 13:40:52 CST 2004 : Line = 26 Column = 40 Message = {cvc-complex-type.2.4.a: Invalid content starting with element ‘GML2.gz’. One of ‘{“http://www.opengis.net/wfs”:GML3, “http://www.opengis.net/wfs”:GML2-ZIP, “http://www.opengis.net/wfs”:GML3-ZIP, “http://www.opengis.net/wfs”:SHAPE-ZIP, “http://www.opengis.net/wfs”:XML-OS_SVG, “http://www.opengis.net/wfs”:XML-OS_SVG-ZIP, “http://www.opengis.net/wfs”:XML-TIGER_SVG, “http://www.opengis.net/wfs”:XML-TIGER_SVG-ZIP}’ is expected.}
- Mon Mar 15 13:40:52 CST 2004 : Line = 42 Column = 40 Message = {cvc-complex-type.2.4.a: Invalid content starting with element ‘GML2.gz’. One of ‘{“http://www.opengis.net/wfs”:GML3, “http://www.opengis.net/wfs”:GML2-ZIP, “http://www.opengis.net/wfs”:GML3-ZIP, “http://www.opengis.net/wfs”:SHAPE-ZIP, “http://www.opengis.net/wfs”:XML-OS_SVG, “http://www.opengis.net/wfs”:XML-OS_SVG-ZIP, “http://www.opengis.net/wfs”:XML-TIGER_SVG, “http://www.opengis.net/wfs”:XML-TIGER_SVG-ZIP}’ is expected.}
|

| - | - | - | - | - |

This means that the client performing the request did not request gzip data, got it and could not use it.

David

Gabriel_Roldan1 · March 15, 2004, 2:25pm

oh! I very apologize!
but can’t figure out where the problem goes from.
Look:

in GML2FeatureResponseDelegate:

/** will be true if GML2.gz output format was requested */
private boolean compressOutput = false;

/*if compressOutput == true, then “gzip” will be sent as content-encoding http response header, if not,
no response header will be sent at all/
public String getContentEncoding() {
return compressOutput ? “gzip” : null;
}

//here, outputFormat is the format explicitly requested or just “GML2” by default
public void prepare(String outputFormat, GetFeatureResults results)
throws IOException {
//compressOutput will be true only if “GML2.gz” was explicitly requested
this.compressOutput = “GML2.gz”.equalsIgnoreCase(outputFormat);
this.results = results;
…
}

So I’m a bit confused about what you’re saying.
Is may be that client taking the output format from the capabilities document and can it being getting confused since both “GML2” and “GML2.gz” are specified in capabilities?

are those results from CITE tests? if not, which client is it?

once again, I’m very sorry about that.
can you keep helping me to resolve it the faster possible?

regards,

gabriel

----- Original Message -----
From: David Zwiers
To: Chris Holmes
Cc: Gabriel Roldán ; geoserver-devel@anonymised.comts.sourceforge.net
Sent: Monday, March 15, 2004 9:58 PM
Subject: Re: [Geoserver-devel] GZ GML

Gabriel: You broke the application.

1 REQUEST
CUSTOM A valid document A NON valid document AND
- Mon Mar 15 13:40:52 CST 2004 : Line = 26 Column = 40 Message = {cvc-complex-type.2.4.a: Invalid content starting with element ‘GML2.gz’. One of ‘{“http://www.opengis.net/wfs”:GML3, “http://www.opengis.net/wfs”:GML2-ZIP, “http://www.opengis.net/wfs”:GML3-ZIP, “http://www.opengis.net/wfs”:SHAPE-ZIP, “http://www.opengis.net/wfs”:XML-OS_SVG, “http://www.opengis.net/wfs”:XML-OS_SVG-ZIP, “http://www.opengis.net/wfs”:XML-TIGER_SVG, “http://www.opengis.net/wfs”:XML-TIGER_SVG-ZIP}’ is expected.}
- Mon Mar 15 13:40:52 CST 2004 : Line = 42 Column = 40 Message = {cvc-complex-type.2.4.a: Invalid content starting with element ‘GML2.gz’. One of ‘{“http://www.opengis.net/wfs”:GML3, “http://www.opengis.net/wfs”:GML2-ZIP, “http://www.opengis.net/wfs”:GML3-ZIP, “http://www.opengis.net/wfs”:SHAPE-ZIP, “http://www.opengis.net/wfs”:XML-OS_SVG, “http://www.opengis.net/wfs”:XML-OS_SVG-ZIP, “http://www.opengis.net/wfs”:XML-TIGER_SVG, “http://www.opengis.net/wfs”:XML-TIGER_SVG-ZIP}’ is expected.}

This means that the client performing the request did not request gzip data, got it and could not use it.

David

Chris_Holmes1 · March 16, 2004, 12:23am

I'm pretty sure the problem is just the validation of the capabilities
document. GML2.gz is not an expected output format. GML2-ZIP is, so
maybe we can use that? Not sure if gzip counts as zip... That's
probably the easiest fix - the other option is to use a native element,
I'm pretty sure you can for the output format, but I don't know off the
top of my head how you specify it. It looks like we should maybe also
support the GML2-zip, that's pretty easy to do with java right? Just
use the zipoutputstream? It'd be cool to provide the two options.
Also I'd never really seen that list of valid output formats before -
it looks like providing SHAPE-ZIP is common, as well as SVG. Perhaps
we should provide a featureResponse delegate that uses the svg writer?
So you could request svg from wms or wfs?

Chris

Quoting Gabriel Roldán <gabriel.roldan@anonymised.com>:

oh! I very apologize!
but can't figure out where the problem goes from.
Look:

in GML2FeatureResponseDelegate:

    /** will be true if GML2.gz output format was requested */
    private boolean compressOutput = false;

    /**if compressOutput == true, then "gzip" will be sent as
content-encoding http response header, if not,
    no response header will be sent at all*/
    public String getContentEncoding() {
        return compressOutput ? "gzip" : null;
    }

    //here, outputFormat is the format explicitly requested or just
"GML2" by default
    public void prepare(String outputFormat, GetFeatureResults
results)
        throws IOException {
        //compressOutput will be true only if "GML2.gz" was
explicitly requested
        this.compressOutput =
"GML2.gz".equalsIgnoreCase(outputFormat);
        this.results = results;
        ....
    }

So I'm a bit confused about what you're saying.
Is may be that client taking the output format from the capabilities
document and can it being getting confused since both "GML2" and
"GML2.gz" are specified in capabilities?

are those results from CITE tests? if not, which client is it?

once again, I'm very sorry about that.
can you keep helping me to resolve it the faster possible?

regards,

gabriel

  ----- Original Message -----
  From: David Zwiers
  To: Chris Holmes
  Cc: Gabriel Roldán ; geoserver-devel@lists.sourceforge.net
  Sent: Monday, March 15, 2004 9:58 PM
  Subject: Re: [Geoserver-devel] GZ GML

  Gabriel: You broke the application.

        1 REQUEST
        CUSTOM A valid document A NON valid document AND a.. Mon Mar
15 13:40:52 CST 2004 : Line = 26 Column = 40 Message =
{cvc-complex-type.2.4.a: Invalid content starting with element
'GML2.gz'. One of '{"http://www.opengis.net/wfs":GML3,
"http://www.opengis.net/wfs":GML2\-ZIP,
"http://www.opengis.net/wfs":GML3\-ZIP,
"http://www.opengis.net/wfs":SHAPE\-ZIP,
"http://www.opengis.net/wfs":XML\-OS\_SVG,
"http://www.opengis.net/wfs":XML\-OS\_SVG\-ZIP,
"http://www.opengis.net/wfs":XML\-TIGER\_SVG,
"http://www.opengis.net/wfs":XML\-TIGER\_SVG\-ZIP\}' is expected.}
          b.. Mon Mar 15 13:40:52 CST 2004 : Line = 42 Column = 40
Message = {cvc-complex-type.2.4.a: Invalid content starting with
element 'GML2.gz'. One of '{"http://www.opengis.net/wfs":GML3,
"http://www.opengis.net/wfs":GML2\-ZIP,
"http://www.opengis.net/wfs":GML3\-ZIP,
"http://www.opengis.net/wfs":SHAPE\-ZIP,
"http://www.opengis.net/wfs":XML\-OS\_SVG,
"http://www.opengis.net/wfs":XML\-OS\_SVG\-ZIP,
"http://www.opengis.net/wfs":XML\-TIGER\_SVG,
"http://www.opengis.net/wfs":XML\-TIGER\_SVG\-ZIP\}' is expected.}

  This means that the client performing the request did not request
gzip data, got it and could not use it.

  David

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

David_Zwiers1 · March 16, 2004, 10:37am

Reopened Geos-113 (getCapabilities). With the result returned it is not posible to generate new sessions for cite tests. We have run the tests on both resin 3.0.4 and tomcat 5.0.19 using windows 2k. We should note that struts requires jsp 2.0 (so tomcat 4.X is out). Basically we cannot test until this works. As a side note, the same 42 tests are failing for cite tests with similar reasons for both web containers (lots of getCapabilities, and had some bad validation tests included in the WAR).

David

Chris_Holmes1 · March 16, 2004, 10:10pm

Sorry, I can't get the fix in right now, but I don't think it's that hard.
Instead of returning GML.gz return GML2-ZIP. Or return nothing. Log it
as work done on this issue, and leave it open so we can figure out later
if we should use a native elemnt or something. But for now it just needs
to validate so we can have the rest of the tests work.

Chris

On Tue, 16 Mar 2004, David Zwiers wrote:

Reopened Geos-113 (getCapabilities). With the result returned it is not
posible to generate new sessions for cite tests. We have run the tests
on both resin 3.0.4 and tomcat 5.0.19 using windows 2k. We should note
that struts requires jsp 2.0 (so tomcat 4.X is out). Basically we cannot
test until this works. As a side note, the same 42 tests are failing for
cite tests with similar reasons for both web containers (lots of
getCapabilities, and had some bad validation tests included in the WAR).

David

--