Hi,
for the upcoming RC release of GeoServer 1.7.x we would really like to include the GeoWebCache module to demonstrate new superoverlay functionality (for Google Earth and other KML clients).
Does anyone object / feel we need to go through a more formal process?
It does not modify code in GeoServer, the memory footprint is tiny and it uses HTTP to communicate with the core. If invoked, it creates a "gwc" folder in the data directory or the temp directory.
-Arne
Hi Arne,
How do you want to go about including it? Like baking it directly into the release? I myself would like extensions to be kept as extensions, downloadable separately. However I am all for including an additional artifact with gwc "baked" in.
-Justin
Arne Kepp wrote:
Hi,
for the upcoming RC release of GeoServer 1.7.x we would really like to include the GeoWebCache module to demonstrate new superoverlay functionality (for Google Earth and other KML clients).
Does anyone object / feel we need to go through a more formal process?
It does not modify code in GeoServer, the memory footprint is tiny and it uses HTTP to communicate with the core. If invoked, it creates a "gwc" folder in the data directory or the temp directory.
-Arne
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,4884e7ca296311804284693!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
What do you mean by an artifact with gwc baked in? Like a set of binary downloads that geoserver+gwc-1.7.0?
I think it makes sense to start including gwc directly in the default release, not forcing people to download a separate jar and plug it in. For one the KML super overlay code relies on it directly. And eventually I'd like to make it so our layer preview uses gwc directly - with it automatically killing the cache when you change the config or the style or do a transaction. Then geoserver will always tile things by default, which I think is a huge win.
It should be kept as a separate module, but I think it should be included in the release. I see it as more on the level of like WCS, a service that should ship by default. Eventually we may make a slimmed down release, but for now we already include the kitchen sink.
C
Justin Deoliveira wrote:
Hi Arne,
How do you want to go about including it? Like baking it directly into the release? I myself would like extensions to be kept as extensions, downloadable separately. However I am all for including an additional artifact with gwc "baked" in.
-Justin
Arne Kepp wrote:
Hi,
for the upcoming RC release of GeoServer 1.7.x we would really like to include the GeoWebCache module to demonstrate new superoverlay functionality (for Google Earth and other KML clients).
Does anyone object / feel we need to go through a more formal process?
It does not modify code in GeoServer, the memory footprint is tiny and it uses HTTP to communicate with the core. If invoked, it creates a "gwc" folder in the data directory or the temp directory.
-Arne
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Fair enough, good arguments for making it part of the default distro. I just always think that a very lean and plain core with extensions makes for a nice architecture. But from a product/functionality standpoint it makes sense to include it.
However I do think a plain geoserver with no frills is something that people might want. I could be wrong here... i would be interested in hearing some users take on this. Perhaps we can can call it geoserver-vanilla-bin.zip and make it another artifact.
If it is to be included then suggest we move it from a community/extension module... and just into main. For one so that we don't have to remember to build releases with the geowebcache profile, and two it will mean that extensions we put up for download match extensions modules in the code base.
-Justin
Chris Holmes wrote:
What do you mean by an artifact with gwc baked in? Like a set of binary downloads that geoserver+gwc-1.7.0?
I think it makes sense to start including gwc directly in the default release, not forcing people to download a separate jar and plug it in. For one the KML super overlay code relies on it directly. And eventually I'd like to make it so our layer preview uses gwc directly - with it automatically killing the cache when you change the config or the style or do a transaction. Then geoserver will always tile things by default, which I think is a huge win.
It should be kept as a separate module, but I think it should be included in the release. I see it as more on the level of like WCS, a service that should ship by default. Eventually we may make a slimmed down release, but for now we already include the kitchen sink.
C
Justin Deoliveira wrote:
Hi Arne,
How do you want to go about including it? Like baking it directly into the release? I myself would like extensions to be kept as extensions, downloadable separately. However I am all for including an additional artifact with gwc "baked" in.
-Justin
Arne Kepp wrote:
Hi,
for the upcoming RC release of GeoServer 1.7.x we would really like to include the GeoWebCache module to demonstrate new superoverlay functionality (for Google Earth and other KML clients).
Does anyone object / feel we need to go through a more formal process?
It does not modify code in GeoServer, the memory footprint is tiny and it uses HTTP to communicate with the core. If invoked, it creates a "gwc" folder in the data directory or the temp directory.
-Arne
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,4888cbfd188126491211187!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira wrote:
Fair enough, good arguments for making it part of the default distro. I just always think that a very lean and plain core with extensions makes for a nice architecture. But from a product/functionality standpoint it makes sense to include it.
However I do think a plain geoserver with no frills is something that people might want. I could be wrong here... i would be interested in hearing some users take on this. Perhaps we can can call it geoserver-vanilla-bin.zip and make it another artifact.
Sure. Maybe do a blog post with a poll or something? I think it could be of interest, though the counter point is that no one has ever asked for it or even complained about the size of GeoServer (except for me when I was in Africa).
If it is to be included then suggest we move it from a community/extension module... and just into main. For one so that we don't have to remember to build releases with the geowebcache profile, and two it will mean that extensions we put up for download match extensions modules in the code base.
Sure. If it's a bitch to do this week I think we might just do the release with the profile, and be sure to move before the next release.
C
-Justin
Chris Holmes wrote:
What do you mean by an artifact with gwc baked in? Like a set of binary downloads that geoserver+gwc-1.7.0?
I think it makes sense to start including gwc directly in the default release, not forcing people to download a separate jar and plug it in. For one the KML super overlay code relies on it directly. And eventually I'd like to make it so our layer preview uses gwc directly - with it automatically killing the cache when you change the config or the style or do a transaction. Then geoserver will always tile things by default, which I think is a huge win.
It should be kept as a separate module, but I think it should be included in the release. I see it as more on the level of like WCS, a service that should ship by default. Eventually we may make a slimmed down release, but for now we already include the kitchen sink.
C
Justin Deoliveira wrote:
Hi Arne,
How do you want to go about including it? Like baking it directly into the release? I myself would like extensions to be kept as extensions, downloadable separately. However I am all for including an additional artifact with gwc "baked" in.
-Justin
Arne Kepp wrote:
Hi,
for the upcoming RC release of GeoServer 1.7.x we would really like to include the GeoWebCache module to demonstrate new superoverlay functionality (for Google Earth and other KML clients).
Does anyone object / feel we need to go through a more formal process?
It does not modify code in GeoServer, the memory footprint is tiny and it uses HTTP to communicate with the core. If invoked, it creates a "gwc" folder in the data directory or the temp directory.
-Arne
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
I could write a blog post about this if no one else volunteered. I'd be curious to see what people's reactions are (if any) to the bundling of GWC. Personally, I'm all for it, but I like software that does lots of things right out of the box. 
There's another suggestion that this brings up. Perhaps if we're going to do a "bundle" release of GS+GWC, perhaps we should go full tilt on it, and include _all_ of the extensions. That way the people who want plain vanilla get it by default, and those people (like me, and possibly others) who want everything in one simple download, get that as an option too.
$0.002,
Mike
* Why do people think vanilla is plain, anyway?
Chris Holmes wrote:
Justin Deoliveira wrote:
Fair enough, good arguments for making it part of the default distro. I just always think that a very lean and plain core with extensions makes for a nice architecture. But from a product/functionality standpoint it makes sense to include it.
However I do think a plain geoserver with no frills is something that people might want. I could be wrong here... i would be interested in hearing some users take on this. Perhaps we can can call it geoserver-vanilla-bin.zip and make it another artifact.
Sure. Maybe do a blog post with a poll or something? I think it could be of interest, though the counter point is that no one has ever asked for it or even complained about the size of GeoServer (except for me when I was in Africa).
If it is to be included then suggest we move it from a community/extension module... and just into main. For one so that we don't have to remember to build releases with the geowebcache profile, and two it will mean that extensions we put up for download match extensions modules in the code base.
Sure. If it's a bitch to do this week I think we might just do the release with the profile, and be sure to move before the next release.
C
-Justin
Chris Holmes wrote:
What do you mean by an artifact with gwc baked in? Like a set of binary downloads that geoserver+gwc-1.7.0?
I think it makes sense to start including gwc directly in the default release, not forcing people to download a separate jar and plug it in. For one the KML super overlay code relies on it directly. And eventually I'd like to make it so our layer preview uses gwc directly - with it automatically killing the cache when you change the config or the style or do a transaction. Then geoserver will always tile things by default, which I think is a huge win.
It should be kept as a separate module, but I think it should be included in the release. I see it as more on the level of like WCS, a service that should ship by default. Eventually we may make a slimmed down release, but for now we already include the kitchen sink.
C
Justin Deoliveira wrote:
Hi Arne,
How do you want to go about including it? Like baking it directly into the release? I myself would like extensions to be kept as extensions, downloadable separately. However I am all for including an additional artifact with gwc "baked" in.
-Justin
Arne Kepp wrote:
Hi,
for the upcoming RC release of GeoServer 1.7.x we would really like to include the GeoWebCache module to demonstrate new superoverlay functionality (for Google Earth and other KML clients).
Does anyone object / feel we need to go through a more formal process?
It does not modify code in GeoServer, the memory footprint is tiny and it uses HTTP to communicate with the core. If invoked, it creates a "gwc" folder in the data directory or the temp directory.
-Arne
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4051,4888d99a225531096210785!
------------------------------------------------------------------------
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/!DSPAM:4051,4888d99a225531096210785!
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4051,4888d99a225531096210785!
Mike Pumphrey ha scritto:
I could write a blog post about this if no one else volunteered. I'd be curious to see what people's reactions are (if any) to the bundling of GWC. Personally, I'm all for it, but I like software that does lots of things right out of the box.
There's another suggestion that this brings up. Perhaps if we're going to do a "bundle" release of GS+GWC, perhaps we should go full tilt on it, and include _all_ of the extensions. That way the people who want plain vanilla get it by default, and those people (like me, and possibly others) who want everything in one simple download, get that as an option too.
There are significant differences between the various extensions and
some good reasons why just do not bundle some of them in the
main download:
- arcsde datastore has licensing issues, we cannot include the jars
needed to make it working
- oracle, mysql, db2, vpf, mif, gml, pyramid have small or big
functionality and maintainership issues. Providing them as extensions
makes it clear that they are not standing at the same level as
shapefile or postgis
- wfsv has youngness issues, the datastore changes the structure of
your database permanently and the protocol is not that well tested
GWC does not share any of the above weaknesses, so I'm favourable to
add it as a standard module, but I would be quite concerned to bundle
the others.
Cheers
Andrea
Those are fair concerns.
Just for some history, is there a precedent for this? Has there been a package/extension/plugin that existed separately from GeoServer in the past that has subsequently been built-in? It's more curiosity/blog-fodder than anything else...
Thanks,
Mike
Andrea Aime wrote:
Mike Pumphrey ha scritto:
I could write a blog post about this if no one else volunteered. I'd be curious to see what people's reactions are (if any) to the bundling of GWC. Personally, I'm all for it, but I like software that does lots of things right out of the box.
There's another suggestion that this brings up. Perhaps if we're going to do a "bundle" release of GS+GWC, perhaps we should go full tilt on it, and include _all_ of the extensions. That way the people who want plain vanilla get it by default, and those people (like me, and possibly others) who want everything in one simple download, get that as an option too.
There are significant differences between the various extensions and
some good reasons why just do not bundle some of them in the
main download:
- arcsde datastore has licensing issues, we cannot include the jars
needed to make it working
- oracle, mysql, db2, vpf, mif, gml, pyramid have small or big
functionality and maintainership issues. Providing them as extensions
makes it clear that they are not standing at the same level as
shapefile or postgis
- wfsv has youngness issues, the datastore changes the structure of
your database permanently and the protocol is not that well testedGWC does not share any of the above weaknesses, so I'm favourable to
add it as a standard module, but I would be quite concerned to bundle
the others.Cheers
Andrea!DSPAM:4051,488ec82b93493668746562!
Mike Pumphrey wrote:
Those are fair concerns.
Just for some history, is there a precedent for this? Has there been a package/extension/plugin that existed separately from GeoServer in the past that has subsequently been built-in? It's more curiosity/blog-fodder than anything else...
We have provided an optional download (for supporting additional datastores) in the past. Idea was people downloaded the zip file and extracted it into their geoserver install. Justin has 2 proposal about this kind of thing now as he explores the difference between a community module and an extension.
Jody
Mike Pumphrey ha scritto:
Those are fair concerns.
Just for some history, is there a precedent for this? Has there been a package/extension/plugin that existed separately from GeoServer in the past that has subsequently been built-in? It's more curiosity/blog-fodder than anything else...
Yes, we did, it's the wfs datastore, that we now bundle in order
to support a WMS operation mode called feature portrayal service:
basically in your SLD you specify not a normal layer, but a remote
one pointing to another WFS server, and GeoServer pulls the data
in and renders it.
Cheers
Andrea
