On Thu, Jun 21, 2012 at 9:36 AM, Jody Garnett <jody.garn...@gmail.com>wrote:
>
> Ugh, implemented as you suggest it will affect performance of WPS chaining
> a lot.
>
> This is due to the removal of the subCollection methods, which are the
> only way to have a streaming process
> (one that returns a computing collection) compute less data if a
> downstream process needs less.
> This approach is not used much now, but killing it right away will make it
> impossible to setup
> process chaing that efficiently work in pull mode.
>
> subCollection(Query) method is still there.
>
> Sorry I did not look closely at the proposal, I only deprecated what it
> described, and left the sort and subCollection methods in place (as it also
> described). I will double check the remaining methods and update the
> proposal page if you like. I am more focused on the patch right now.
>
The comments in the jira should be removed them, they are misleading.
I would also remove the commented out portion out of the patch, as they add
more confusion as well
I think it was a request for consistency, when this proposal was first
> written we had just made all the feature/attribute methods have a
> getTypeMethod().
>
> I think getDescriptor() is simply missing.
>
Still don't get it. The need is either clear or it should be left out.
> The rest about removing all the modification oriented methods from feature
> collection seems
> reasonable to me, I always think about feature collections in terms of
> something that is
> a "view" of a store. Real in memory collections can offer modification
> methods of course,
> and we should update demo and tutorial code accordingly.
>
> Yep, indeed I updated he "addFeatures" example to use a
> ListFeatureCollection rather than DefaultFeatureCollection yesterday.
>
Nice
> One thing that still bothers me a lot about current collections is that
> they never throw a IOException,
> this is still a vestigial decision from the "collection is a memory thing"
> times, and makes it harder
> to write an implementation that actually does I/O ("ouch, this code does
> IO but I cannot declare
> these IO exceptions...").
> I understand changing this would break a lot of client code, just ranting
> here.
>
> It is a good rant I understand.
>
> My own rant was a wish that FeatureIterator (and FeatureReader) would
> implement Closable.
>
Hum... I believe it could be done on the new trunk, but Closeable throws
IOException.
If we need to have one method thwoing that excpetion, better have them all,
no?
Cheers
Andrea
--
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
