Ok, so I meant to sound in on this discussion awhile ago, but the blackout
in the midst of trying to get a release out left me a bit swamped. First
off, I'd like to see wms-server out of geotools, as I agree that it
doesn't really fit there.
As for 2 vs. 3, I have no real strong preference, though if people want to
see it as a direct part of GeoServer then TOPP will definitely work to
support it and consider it a core part of our project.
I'm planning on integrating gt2wms with GeoServer sometime after
September, whether it is living on another project or with GeoServer. If
it is already living with GeoServer then I will make efforts to unite the
common classes as much as possible, if not I'll probably contribute to
gt2wms and rewrite some of it to make access easier, as my goal would be
pretty much to have gt2wms be able to use GeoServer's configuration
structure. I probably wouldn't spend a lot of time coding GeoServer to
use gt2wms's configuration, though it probably wouldn't be too hard with
changes I might make.
But I do see some potential overlap, both with configuration and with some
of the requests and exceptions, so there are some good arguments for
combining the projects. GetCapabilities in particular is very similar,
and most of it's information comes from configuration files, so we could
probably share the same classes for those. Exception reporting I believe
is also similar. I also see benefits from more developers on both
projects, thinking about common issues that both may run into but that
one may hit a lot more. Advances in one would obviously be easier to
apply to the second if the code lives the same place. I've also actually
been working to make GeoServer's configuration classes able to run fairly
generically, they handle our directory structure of features (layers in
the wms parlance), but they could easily handle flat files like gt2wms's
configuration, with a few advances to read the wms particular elements.
As for the design goals and not wanting to burden users with having to
deal with a wfs when all they want is a wms, I would point to GeoServer's
users, who generally don't have too hard of a time getting it all working.
Most of the problems of setting up GeoServer are the stuff needed before
it, getting and installing a servlet container and postgis. Those are
needed to get gt2wms up and running as well, they just are more glossed
over in the user docs. And GeoServer definitely tries to be as
lightweight as possible, a thin layer on top of geotools, which is why we
contribute so much to the gt2 project. As Ugo mentions, users could
easily use GeoServer with an integrated WMS and just choose not to use the
WFS, and they needn't worry about it all. The WMS actually has a more
complex configuration needs, from what I could tell.
I think the main difference right now between the two projects, at least
from a user who only knows one or the other, is how you get it. Gt2wms
you download a war, GeoServer you download the directory structure and
build the war. I'd never really thought about it for today, but I think
GeoServer should consider offering a war directly, a lightweight option to
users. I _peronally_ like being able to build the war myself, as it's
much easier to save your configuration changes. With gt2wms, you have to
know how to create a war on your own if you want to save it for later use.
With GeoServer I back-up and drop in a lot of different wars, and I like
that flexibility. I think this is an example of an area where the
projects could benefit from the other, as gt2wms could tap right into
GeoServer's build and configuration structure, and geoserver can start
delivering wars for direct use, for users who just want to change the
configuration files in their webapps structure. We could even make a
download on the GeoServer site called gt2wms, as a jar, and users wouldn't
even have to know that there is some wfs code in there.
I've also been glancing over the OGC's discussion specs
(http://www.opengis.org/info/discussion.htm), espcially the Web
Object Service (WOS) spec, which presents a generic way to transfer
objects, to serve as a generic root for objects over the web. It's based
on the WFS, but more generic. There's also a number of other Web Services
up for discussion, and I think that by combining the current web services
by the gt2 team (wfs and wms), we can more easily think about rolling
the common elements back into the geotools code base. We'll already have
geotools team members working in conjunction, making the integration
Granted most of this doesn't really matter as to where the gt2wms actually
lives, as TOPP is definitely going to be contributing to it soon, where
ever it may live, as an integrated WMS in GeoServer will be quite nice to
have, and the gt2wms is already in good shape and leverages the same code
base. I actually don't feel as strongly as Rob about not having it live
in another location. I would like to see that work done _after_ the beta.
But if Ian already has to work on it and support it anyways, it doesn't
matter so much. But I agree that the GeoServer user base could be helpful
for testing purposes, and I think developers thinking about common
problems in both could be good. But I personally see the differences as
not too major, since as I said before, we will be integrating gt2wms, even
if it lives in another location. I guess the difference is really in how
they are marketed, if GeoServer should be primarily seen as a WFS, gt2wms
as just a WMS, or if they should be seen as something more coherent, for
users to use as they will. I see benefits and drawbacks to both. So I'll
wrap this up and say I'm fine with either 2 or 3, and am going to put some
dev time into gt2wms where ever it may live, and will do what I can to
help out with support once I contribute and know it a bit better than I do
On Fri, 22 Aug 2003, Ugo Taddei wrote:
> I've been following this discussion and thought I'd give some feedback
> from the point of view of a user.
> > On Friday 08 Aug 2003 9:30 pm, James Macgill wrote:
> >>The three options as I see them are:
> >>1) leave wmsserver where it is, but leave it out of any formal releases
> >>(i.e. what happens now)
> >>2) start a new project specifically for the wmsserver module
> >>3) merge the wmsserver module into the GeoServer project.
> GeoServer and gt2WMS have so much in common - i.e. sharing the GeoTools
> framework - and are really complementary applications, that I find the
> wmsserver module should be embraced by the GeoServer Project.
> I don't find GeoServer more difficult to download and deploy than
> gt2WMS. (And isn't that something that can be tackled by documentation?,
> that is, how to install, configure and use.) If users should find
> difficult or should not want a WFS, then they need not give attention to
> GeoServer's WFS. But the WMS should be a module, that is, part of the
> GeoServer project.
> Furthermore, I've seen GeoServer's svg-based GeoClient and found it
> nice. I then made some minor alterations to the GT2 WMSServlet to output
> the image as svg and the result was reallly pleasing (for so little
> extra work). (Though I think output as raster is as important.)
> That is, you guys got so much in the hands, and despite not being any
> official release, both tools (GT2 and GeoServer) are looking great. I
> wish for option 3 (and hope to contribute to the project one day, but
> I'm still doing my homework: installing all that software and reading
> through the docs).
> PS.: I realise that I'm not authorised to send messages to gt2-devel,
> but hopefully you'll let my message through and get my point ;-)
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
> at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
> Geotools-devel mailing list