On Wednesday 06 February 2008 08:18:41 pm Justin Deoliveira wrote: > Gabriel Roldán wrote: > > Thanks for the feedback, > > > > though I'm not sure why you're complaining about getInfo() as it has > > nothing to do with this proposal? > > like it is a past proposal you can make your voice sound for that one.. > > See the before/after pictures, getInfo() is in the before becuase it is > > in the api before the introduction of FeatureAccess. > > Yeah, i stated that it was off topic. I can start a different thread on > it if you wish. And i did voice distaste for it but it appears it went > forward anyways.
hmmm.. I'm not even pmc, but as it got 3 positives and no negatives I guess that's why it went forward... still, feel free to ask who you need to ask about that, I was told what I've been doing with WFS client code where duplicating that proposal work (that is, providing information the wfs datastore were already doing and being used by uDig), and instead of duplicating just joined. Now, in my opinion that's what trunk is for. Gabriel > > > ah, another read at the proposal made me see there was something about > > FeatureResourceInfo... that was discarded and would have been there by > > mistake, removed it. > > > > Cheers, > > > > Gabriel. > > > > On Wednesday 06 February 2008 08:00:19 pm Justin Deoliveira wrote: > >> Here is my feedback: > >> > >> * getInfo() > >> > >> I guess this is a little off topic of this proposal and related to the > >> last. But I was surprised when i saw it go through today. I remember > >> having voiced feedback about those interfaces not being fine tuned > >> enough. All those attributes: schema, publisher, title, etc... dont > >> apply in the common case, they really only apply to WFS as far as i can > >> see. > >> > >> What I want is to have a bare minimum. Like just uri. Everything else > >> like the above can be thrown in a subclass. That way implementors can > >> chose to implement additional metadata interfaces if they choose, and > >> only a minimum in the normal case. > >> > >> Also some of the attributes (like icon), need to be rethought. An icon > >> is something that a ui will want to set, not something provided by a > >> datastore implementor. > >> > >> I also think ServiceInfo and GeoResourceINfo are bad names. They imply > >> catalog, and as it says in the proposal "they are not catalog". > >> > >> I dont know why my vote says +0... i remember having serious > >> reservations on this one. Perhaps it is because i disapeared over this > >> last week. > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Geotools-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
