Justin Deoliveira wrote:
>> It seems to me that GeoTools requires wide-ranging
>> backwards-incompatible changes to better support namespaces. This may
>> cause inconvenience to those who have code based on GeoTools.
>>
>> (1) Does the community want to see such a change?
>>
> Yes, but my experience with changing apis over to Name is that much of
> it can be done in an additive way. The only pain is occurs when a class
> returns a list or array of String, and now we need name.
Indeed. In the case of Query:
public interface Query {
String[] getPropertyNames();
>> (2) How should it be done? (I am looking for suggestions of where to
>> start, and other areas that will need work.)
> Query seems to be a logical place to start perhaps. I would say add the
> methods necessary to keep in tact the qualified property names and types
> names passed into the query.
If I can avoid changing Query, I will for now; non-simple DataAccess can
just return all properties. When we change Query, it will require a
proposal, because it is a public API.
>> (3) Who is able to help?
> I am happy to review any patches. As with the geoserver changes, I would
> like to see a patch representing a "spike". Apply it so i can review and
> provide additional feedback.
Thanks! I'll see how far I can get.
--
Ben Caradoc-Davies <[email protected]>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
