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.
I have added a couple more items for motivations.
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
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