Andrea Aime wrote: > Jody Garnett ha scritto: >> Hi Andrea, going to try and give you a decent reply (think of this as a >> preview of the planning we will do in January, although given your >> concerns perhaps earlier) >>> As I stated, I cannot work on 2.4 because ows4 branch is just a WFS >>> 1.1 implementation, not a Geoserver I can ask a use to try out. See >>> my answer to Rob comments. >> It seems insane that the OWS4 branch has let go of a user interface and >> other creature comforts - I agree that it places the entire work in >> danger of being ignored (well it is already being ignored by you so the >> observation is moot). > > No, I don't think it'll be ignored.... it's just that the current > geoserver user interface and configuration subsystem are the antithesis > of any effort to produce clean code. So I guess Justin threw them > out of the window in order to provide a cleaner base for the Geoserver > of the future. > > There is common agreement among every geoserver developer I know that > the current UI and config subsystem need to be replaced. Yes they are gone because for my work they were more trouble then they were worth. And yes I through away the old config system. But using some reflection and a spring brean i have already written I could bring back a new one in about an hour.
As for UI ( and this is just my opinion ), a pretty useful one could be written in a short time frame that is a lot simpler then the current one and just as useful if not more. > >> The amount of effort going into making the kind of operations you are >> working on easy to produce on that branch makes it the obvious choice >> for you - > > It's not really so big a change, I can do it on geoserver trunk as well. > WFS modules are also changing too fast now that Justin is really testing > against the new CITE tests, so we would get one in the way of the other. > OWS4 will be a better place when the dust is settled off, but at the > moment it's a one man game. > >> but without a clear road map you are going to be wasting your >> time either way (either reinventing work done to make producing OWS >> operations easy, or work not done to wrap a user interface around the >> end product). > > Initial WFS port from Justin hasn't been such a mess for him, mostly > cut, paste and fix. But I agree the more complex protocol using > branches could be developed on ows4 the day it becomes trunk. Yeah, not much of the old code changed which was the whole idea. Howerver, there have been some significant changes. I do think we need a good way to track the changes that andrea is going to be making to the wfs code so that I can incorporate them onto the ows4 branch. I dont want this to be another complex-features nightmare. > >> Andrea I would ask for a road map during todays GeoServer >> meeting before writing OWS4 branch off ... something we also need to >> have for Rob's planning no doubt. > > Sure. > >> Regardless during today's GeoServer meeting we should try and figure out >> when a version of GeoServer will work on 2.4. The answer my be build >> around Simone's schedule - as I recall, he needed his GCE replacement >> ready by the end of GeoTools 2.4. If the OWS4 branch makes it home in >> time fine, if not changing over to 2.4 is not a big deal (and the >> earlier the better). > > I fully disagree here. Once 2.4 gets in the state of the current 2.3, > that is relatively freezed, no big API changes, then, and only then, > Geoserver will consider moving over. Hopefully this will happen in > a few months. > >>>> This kind of thing (extending the content GeoTools can work with) is >>>> exactly the kind of change that should not cause a ripple to the >>>> library, and instead we are left with a workaround. >>> Just for the sake of discussion and comprehension, how working on 2.4 >>> would benefit my work, besides the obvious that the required changes >>> should not go in a stable branch? >> Well you would be on trunk with other active developers, so when you ask >> for feedback you will have it in an more timely fashion. Normally being >> on trunk is advantageous over a branch since your work has a better >> chance of appearing in a release, and not falling out of sync with >> ongoing development. Even working on 2.3 I would advice you to stay >> away from deprecated methods (since alternatives are available to you in >> the 2.3). > > Jody, look at the last two months Geoserver developement. We're seeking > stability, not exciting new features at the moment. > Versioning is a small divesion, but then we'll have tiled map server, > which is something to be worked on the geoserver side, and so on... > >> On the technical front you could package up your new content >> (feature+version) in a FeatureFactory and be done with it. You may also >> leverage justin's xml binding system if it seems appropriate (actually >> not having this available for defining and parsing your new requests and >> responses is the worst thing about this situtation). You may also >> enquirer if Justin still has plans to backport - he was aiming for basic >> functionality and documentation which he has since achieved. > > I don't know... we're supposed to switch to the new xml stuff along with > wfs 1.1, that is, what will become geoserver 1.6 or eventually 2.0 We are not sure what the exact target will be. After ows4 is all done the next task is going to be documentation and coming up with a good game plan to bring this stuff home. I can see some stuff getting on sooner then later, some stuff waiting until later. > >> The other advantage is the work going into making oracle datastore (and >> indeed any datastore) easy to write and maintain. If I had you producing >> a JDBC baesd datastore I would be free to work on the supporing classes >> (that both you and justin would use). I have every confidence that your >> work would finish sooner then you wasting your time subclassing >> JDBCDataStore. > > I'm subclassing postgis datastore, and already written 500 loc :-p > I guess I'll have a working datastore by mid of next week. > >> Finally I should stress that 2.4 is a short release cycle, once it's >> targets are done it too will be locked down (in about a months time?). > > Cool, this means it'll be ready for 1.6 > >> And then the real work will begin - but that is a tale for another time >> (and possible delayed until we can seek a round of funding). >>> I mean, even in 2.4 I would have to extend Feature and fix the GML >>> handlers to handle the newly added version attribute. >>> What other shiny new roads would the ongoing 2.4 work open for me? >> Binding+Writing as a replacement for your GML handling as well. Can you >> think of a nicer way to parse out your GML+version information when it >> is supplied during a request? Not to sound unusually bullish, but it is >> the right tool for the job. > > I don't disagree, but it seems to mesomething for the future, not for > today. When we go the new XML binders, all geoserver will switch. > Justin, I'm interested in your opinion here: shall I try to parse then > new requests with your binding framework or, since they just slight > variations of the old requests, I can go without problems with the old > one? You could, however... The bindings I have written parse requests straight to an emf model which has been generated from the wfs schema. To use them you would either have to use that model, or write bindings that would create objects in the old model. Xml production however should slot it seemlessly. > > Cheers > Andrea > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > !DSPAM:1004,4575a75e275092207481331! > -- Justin Deoliveira [EMAIL PROTECTED] The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
