Re: [Geotools-devel] DataAccess on the way out; how do you want to get ISO Feature in?

[Jody G. <jga...@re...>]

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.

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
>>     
>
>