Re: [Geoserver-devel] GSIP#9 New Catalog

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

Thanks for the feedback Andrea, and I agree the examples do not impress :-)

I will be sure to note Query (or visitor?) by resource type is noted as 
a user story.

Please note there are two ways in which a catalog may be employed 
(actually different architecture layers):
- Run the existing "Data Model" of info objects (access to Styles, 
Schema); and use a catalog api to manage resource connections 
(FeatureType, Features)
- Use a catalog api to serve up the existing data model; ie provide 
access to the Info objects, Features, Schema, Styles, FeatureType, Features

Andrea I think I should take the catalog api discussion to the GeoTools 
side of the fence; it needs to be improved regardless of GeoServer's plans.
Jody
> Jody Garnett ha scritto:
>> Well to start out with I would really like it if we did not have to 
>> use a new catalog, and could instead run with the same one used by 
>> uDig. At the very least my point of success here is having both 
>> applications make use of the same implementation (as was pointed out 
>> in the meeting we need to find ways to reduce the amount of work, 
>> sharing is one such way).
>>
>> Thank you for the code examples Justin; they help evaualte the api - 
>> once again the big picture is going to hold back acceptance of this 
>> idea.
>>
>> I have updated the page to link to the geotools proposals for 
>> improvement, and the existing uDig documentation. I see lack of 
>> documentation and testing as an issue, The GeoServer team can have 
>> access to a well tested implementation if they wish; back porting to 
>> Java 4 would be the issue.
>
> Having just one implementation would be good for sure.
>
> Btw, I've been looking at the code samples and I'm definitely not 
> impressed.
> Having the service finder separate from the catalog may
> be a nice way to structure the inner usage of the code, but as an API
> user I would like to be shaded from it (inner vs outer API).
>
> On the last example, looking up a feature type that way seems to be
> a lot complicated, and procedural too... If these are the inner
> working of a lame catalog implementation fine, but again as a user
> I don't want to see them. An implementation that can scale and
> perform should use something better than an inner loop thought
> (a database with indexes, whatever).
> Otherwise we would suffer from the same sins as our current
> catalog system: Simone has had thousands of feature types in Geoserver,
> and things like looking up the feature type by looping on them
> were taking more time than processing the actual response.
>
> Cheers
> Andrea