Heads up x2 You are probably not going to get a geoserver branch; everyone is doing everything they can to slow down and work together (a branch runs counter to that - it allows you to move quickly but alone).
Justin perhaps it would be good if you outlined the conditions under which you would allow a branch to proceed? I am thinking three weeks max; specific RnD goal; and a plan to bring the work home (even if the work is just a report). I am sure GeoTools would love having you whip "trunk" into shape but please keep the GeoServer codebase in mind as well. On a related note Rob I would like to bounce a class diagram off you on what you think the configuration needs of a "real" GeoServer is (from your email I understand that includes XSD files provided by the end user; I can surmise that it include a declaritive "application profile" (saying if things like if the GetInfo opperation is turned on or not; and that is where I start to slow down - on your branch in the past there was a "mapping" step that I would like to hear you talk about ... don't worry about it making detailed sense I just need to hear what kind of language you use as I am trying to understand the problem). Cheers, Jody > Jody Garnett wrote: > > Right - I understand what you are doing. But what we really want is > > you to update "the 1000 bugs" caused when the geotools codebase > > switches to FeatureTypeBuilder and FeatureBuilder. > > > > We need you to do this work (or organize a work party of volunteers to > > get it done). Basically put it in your plan, we need some help on the > > leadership side here Gabriel - and you are point man for Feature right > > now. > > > Heads up: > > Once I have the ability to propagate real features through a geoserver > branch I'll be testing this extensively across a range of backend data > stores and Feature Types. I'll be focussed on WFS:GetFeature and > WMS:GetMap and WMS:GetFeatureInfo, but will also be peripherally testing > the getCapabilities calls. > > I'll probably have a look at DescribeFeatureType, but have significant > doubts about its usefulness - to I think it shuld simply redirect to the > authoritative schema for nearly all real world cases where the client > doesnt already know the feature. There is a case however for it to > produce an arbitrary 'flattened' convenience view of the schema derivation. > > Anyway, last time I probably fixed most of the bugs on the Oracle list, > on the complex-features branch but had no time to consider porting them > back to the old geotools versions to make them available, and especially > to set up tets cases outside the specific community schemas I am asked > to support. Anyway, I'm confident that with trunk-on-trunk we can get a > lot of useful testing and bug fixing happening once community-schema > module can be used. > > Rob A > > Cheers, > > Jody > > > >> On Monday 12 February 2007 21:40, Jody Garnett wrote: > >> > >>> Hi Gabriel; I have watched your todo list take place on the wiki ... > >>> can > >>> you fill us all in on your plan? We can even start with your ideas from > >>> todays meeting (I am sorry I had to shut you down so hard we had an > >>> agenda to keep - and you were told a month ago you could not proceed > >>> along those lines). > >>> > >> > >> Hi, yes I need to update the progress and plan on the wiki. Some > >> things were arising during the actual work, others can be planned. > >> Basically what there is already on unsupported is the FM ported and > >> passing all the tests as they were on the fm branch. I'm also porting > >> the complex-datastore, which is passing the tests using a memory > >> datastore. To finish poring it I still need to fix the mappings > >> configuration reader. > >> > >> So, the thing regarding DataAccess, and I need this to be really > >> clear, is that I'm not proposing switching to it or forcing anything. > >> It is true that I was told not to go that way, but it is also true > >> that for this run it is impossible to make the "API injection", aka > >> making old extend new, since that would be the hugest API shift in > >> the geotools history. It is also true that for stressing the new FM > >> with real world complex FeatureTypes I need a way to query and read > >> data (ISO Features), which DataStore is not up to the business, right > >> now. > >> So I (temporally) took the FeatureAccess idea since it plays well in > >> providing out of the box support for stuff like getCount(Query) and > >> getBounds(Query) and as an extension of DataStore gives me a place > >> where to train with Source.access(Filter) and the like. > >> That is to say, DataAccess might well be killed at any time you want, > >> I don't care, it is not my fight to impose a new data access api. > >> Moreover, once Justin or whomever make GTFeature extend ISOFeature, > >> DataStore may keep serving as well as it did until now. > >> In conclusion: what I'm doing is making FM work in an unsupported > >> space, with the perfectly set limitations of not breaking anything in > >> supported land, and that's why I need also an unsupported data access > >> method, which I'm glad to switch over to the supported data access > >> api once it is feasible. > >> > >> > >>> So rather then be a brute let me know how you can use help (with > >>> planning *only* I have no coding cycles to spend on this right now). > >>> > >> > >> You already gave me a lot of help with the filter work, thanks to > >> that I am being able of working with ISO Feature at all. > >> > >> In the next days I am going to propose a way (pure implementation > >> details) to enable Filter handle namespaces. > >> > >> More than that, thanks for keeping in sync, I guess the floor is mine > >> and have to update the status of the project. > >> > >> Cheers, > >> > >> Gabriel > >> > >>> Jody > >>> > >> > >> > > > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
