On Fri, 8 Aug 2003, Jody Garnett wrote:
Hey Chris -
My first thought is we should move this interesting conversation to the
devel list.
(But you might not want to get everyones hopes upSo I'll let you
forward this email if you want...
Certainly. I'm fine with getting people's hopes up as long as we can meet
them, which I'm sure we can.
>>Can you run the GeoServer release schedule past me? Are we just waiting
>>for geotools2 now?
>>
So Near as I can tell we are aiming for an End of September 1.0 beta.
With the following general todo list...Required for 1.0:
- Connection Pooling (JDBC 3.0 Seems to provide support hooks)
- I "released" geotools2 jarWishes for 1.0:
- multiple namespace support hacks for GMLBuilder
or GMLProducer with proper namespace support
- Shapefile based Unit Tests
- Code Clean up
Also
- Full filtering with postgis's new geos code. It looks like postgis
might be going to 1.0 pretty soon? Even if it doesn't, it'd be nice to do
overlaps and intersects and all the spatial filtering in the db, instead
of creating geotools features and filtering out with jts.
- more examples of writing queries
- A new GeoClient release? (this one's out of my hands though)
Defer to 1.1
- GMLProducer with complex features support
(will require a Datasource with complex features support)
- Database backed Locking
- GMLProducer with
(or later) - integrated WMS
>>
>>
>I was aiming for 1.0 by the end of september. I'd to release it a bit
>after geotools, and there's a few more issues to resolve. Connection
>Pooling is vital for 1.0 in my opinion. I'd _like_ to move the gml
>generation from GMLBuilder, which is officially the hackiest class ever,
>to the new gml producer. But the nice thing about gml builder is that it
>_works_, even if it's not pretty. There are however two things that it
>just can not handle. One is multiple namespaces in the same response,
>which I guess isn't necessary for 1.0, since we're already doing better
>namespace handling than the spec author's wfs. But I would like it fixed,
>since if someone requests cdf:Nulls and cgf:Lines then the namespace for
>one will be wrong, as the prefixes and namespaces aren't declared
>correctly. Fixing that in gml builder is possible, but would require even
>more hacks, which I don't really want to do, as it'd take quite a bit of
>testing and figuring out. The other thing that GMLBuilder just can't
>handle at all is complex features. I was going to try to motivate these
>before 1.0, but I'm not sure if I'll have time. The new gml producer
>should make it pretty easy to do, but then we also need to figure out a
>datasource that'll support it, a schema for foreign keys in postgis or
>something. I think complex features will also require some work on
>filters as well. So I may hold that off until after the 1.0 release. I
>also need to set up an oracle database so _I_ can test Sean's work and
>write some documentation for using it.
>
I may be able to provide some help there - I will be looking at his work
in september and running some tests at this end. Of course I will be
trying to add locking support but that is another story.
That'd be great. I have to install an os on a computer, and then install
oracle, which by the looks of it isn't the most fun install out there, and
then figure out spatial stuff. The main thing is to write up a section in
the documentation of how to use the oracle datasource, what params are
needed in info.xml. If you'd like to do that Sean I could announce oracle
support on the site, we could put out another point release. I've just
been meaning to test it myself and write it up, but haven't gotten to it.
> And I'd also like to finish a Dispatcher servlet that will allow
> users to post to there and use the same
>root address. So that's basically what's on my plate for 1.0, and I'd
>
I am not sure I understand the dispatcher servlet
The idea is to provide one access point to clients. By the looks of it
some try to send all their requests to the same url, as if it's a cgi
script, even though our capabilities document states where they should be.
There was an email a bit ago called 'Connecting to GeoServer through FME
viewer...' awhile back, where he was saying that fme would ask for
requests like
http://server/geoserver/GetCapabilities?request=GetCapabilities
and then
http://server/geoserver/GetCapabilities?request=GetFeature&typeName=water.
And of course geoserver croaked on it. The dispatcher would allow:
http://server/geoserver/Dispatcher?request=GetCapabilities
and then
http://server/geoserver/Dispatcher?request=GetFeature&typeName=water.
to work just fine, as it figures out the request and forwards it along to
the appropriate servlet. I did an initial fix in cvs, but the guys who
originally wrote it never got back to me, so I'm not sure if it's working,
and I need to set up a windows box to test out the FME viewer. It should
be pretty easy to finish up, I just need to add the transaction operations
and fix up the post requests.
- one idea I have had
is a WFS DataSource which would allow the use of GeoServer as a Proxy
and allow geotool2 based clients an easy communication path.
Yes, I've been kicking around similar ideas for awhile. There's lots of
fun things in that vein. Another thing that would be nice is to write a
geotools interface that is just like a wfs, that would handle figuring out
which actual datasources to send it to, handle all the locking and
whatnot. Basically to move all the data logic to geotools, and to have
geoserver be even thinner, just handle the translation of xml to java
objects and back. It'll also be cool if we ever integrate with deegree,
since then we can just kick features back and forth between our servers as
well. But yes, go forth and code up the Proxy if you feel like it.
>also like to do some massive code clean-up, as a lot of geoserver is
>pretty messy and contains some coding practices of mine and Rob's that
just aren't the best. I guess it's not as important as geotools, as
it's not a toolkit, but I'd still like clean nice code before 1.0. The
other piece of clean-up is unit tests, which I can actually do now that
I've got shapefile support in (we don't have a public postgis instance,
and I didn't want to require sql script creation, but all responses need
a db backend).
>
>
>
>>>I'm also contemplating splitting geotools.jar up into it's components for the geoserver cvs, but I'm not sure about it. Ok, I gotta get outta here and get some food, as I'm starving.
>>>
>>>
>> would try to refrain - just for the sake of your installation process. It is easier for your user's to confirm one version number than five.
>>
>>
>Yeah, you're right. Though I am still contemplating having seperate ones for oracle and shapefile. This is partially due to laziness, however, as then I don't have to figure out my weird problem with shapefile right now, since it works if it's a seperate jar. It'd also nicely emphasize the pluggable nature of datasources, that if one writes the geotools datasource right it can just be plugged right in. So it'd be core/defaultcore/gml/filter/postgis and maybe resources (I need to work out logger issues, I don't really like the updated geotools one) in geotools.jar, and shapefile, oracle and eventually arcsde, mysql, ect. on their own.
>
I was looking over the code - the shapefile jar provides a manafest that
registers the plugin for the DatasourceFinder class. How is
registration handled when the shapefile datasource
is included in the geoserver jar?
When rolling my own jar I just make a new org.geotools.datasourceSpi (or
whatever the file is called) in the manifest, with entries for the postgis
and the shapefile factories. And it worked fine before the geotools
upgrade, but now gives me problems. For a bit I couldn't get either
postgis or shapefile to work, but now postgis will work, shapefile is just
proving tricky. I may be writing the line wrong or something, I just need
to play with it some more.
Chris