GeoTools : 2 November 8th

(11:42:53) jmacgill: we havent started yet... I think some people are still thrown by the time shift
(11:43:07) jmacgill: anyone else from refractions about?
(11:43:26) polio: jesse ... he's home sick (so will probably show around 12:30)
(11:43:59) polio: can get richard if you guys want him to join ... he's making wms talk using post today
(11:44:44) jmacgill: leave him at it for now, we can pull him in if we need him,
(11:45:17) jmacgill: did you see the gt2-users post today?
(11:45:32) jmacgill: from someone wanting to 'port' geotools to eclipse
(11:45:54) polio: yah, just read it
(11:46:02) polio: I should piint him at uDig
(11:46:06) polio: *point
(11:46:09) jmacgill: indeed!
(11:46:53) cholmes ~chatzilla@201.10.93.200 entered the room.
(11:47:12) jmacgill: welcome back Chris
(11:47:53) cholmes: Thanks, sorry for cutting out, I've got this nasty windows problem where rundll32 takes over my processor all the time, and if I want to do any compilation it takes about 50 times as long
(11:48:12) jmacgill: First off, appologies for being late putting the IRC logs online - it took me a little while to work out Jody's new system
(11:48:26) jmacgill: I started getting that on my home machine about a week ago.
(11:48:34) jmacgill: do you know the cause?
(11:48:54) cholmes: No idea, other than that windows sucks.
(11:49:39) cholmes: I could probably use a re-install...I searched for it on google for a bit and found nothing. And I emailed IBM brazil, but in english, and they never got back to me.
(11:50:45) jmacgill: sigh.
(11:50:54) jmacgill: ok, any adgenda Items for today?
(11:51:51) polio: was thinking we could address some of chris holmes datsstore issues
(11:52:07) jmacgill: yeah, that was a v.detailed email Chris.
(11:52:13) jmacgill: let me pull it up for reference
(11:52:13) cholmes: Was just about to say that. Get synced up on metadata plans
(11:52:51) cholmes: Most everything I was fine with actually, just was questioning removing feature reader and wanted to figure out a good approach for metadata discovery, if I remember correctly
(11:53:17) polio: yup think that was about it
(11:53:18) jmacgill: also, what should happen with DataTestCase
(11:53:55) cholmes: As for feature readers, why do they matter so much with transactions?
(11:54:05) cholmes: I was good with removing feature writers.
(11:54:33) cholmes: And yes there is a small issue with a transaction going through while a feature reader is reading, but that could easily be dealt with/documented...
(11:54:43) polio: because we were thinking of adding schema modifications support ... but that requires alot of fancy back-pointers with feature readers from the datastore (ie without an associated transaction)
(11:55:05) cholmes: That said, and as I said before, I'm not incredibly in need of feature readers...
(11:55:42) cholmes: I just sort of like them when I contemplate joins (wink)
(11:56:05) cholmes: schema modification support == featureType modification that goes through to the backend?
(11:56:21) polio: yup
(11:56:33) polio: and crosses transactions
(11:57:00) polio: so the transaction would know the schema modification ... and reset some (but not all, only required) readers/writers
(11:57:36) cholmes: But you're only interested in deprecating feature readers/writers, not removing from the classes that use them, right?
(11:57:43) csdillard: Perhaps I misunderstood what has been suggested, but won't writers go away?
(11:57:44) cholmes: Or were you going to completely redo them?
(11:58:14) polio: well, I wanted to remove them ... but was gently pushed away from that
(11:58:25) polio: so took the next best step ... deprecation
(11:58:53) csdillard: A question: If writers are removed (deprecated), what API remains for writing features? Only "addFeature(Reader)"?
(11:58:56) cholmes: well, deprecation is essentially slowly removing them...
(11:59:10) cholmes: no through a featureSource - add, update, delete
(11:59:26) cholmes: You just want them out of the DataStore, right David?
(11:59:44) polio: correct
(11:59:55) polio: feature source is fine with me (has a transaction)
(12:00:52) jmacgill: so readers and writers go away and we are left with FeatureSource
(12:01:24) cholmes: Ok, this makes sense to me - the only slight concern I have is why it took me this long to get at your reason for wanting it gone - I fear that if I find a hole in this transaction argument then there will be another reason to get rid of them...
(12:01:52) cholmes: Which is of course valid, as I know you don't like them much, and I do need a compelling reasons to get rid of them (smile)
(12:02:37) polio: well, the reason I started looking into changing this was originally I was slated for schema mods this month
(12:03:14) csdillard: An ease-of-use question: In this suggested world, to add a feature I get a FeatureStore. Then I call FeatureStore.addFeatures(FeatureReader), right?
(12:03:24) csdillard: Where do I get a FeatureReader?
(12:03:49) csdillard: (if I just want to add a few hand-made features and quit)
(12:04:03) cholmes: Yeah, I just would have agreed a lot more easily if I'd known that was the reason behind it, the lack of transactions - before I only ever heard that it was bad to mix low and high apis.
(12:04:04) polio: yes, some of the other proposed changes (a while ago) included a random access api for featureSource
(12:04:26) cholmes: FeatureSource.getFeatureResults().getReader()
(12:04:31) cholmes: which could use a bit of a change.
(12:04:51) cholmes: We should resolve our featureResults, featureReaders, featureColleciton feature iterator mess some how
(12:04:59) cholmes: As they all do very similar things
(12:05:17) jmacgill: and I for one am very confused by it
(12:06:14) polio: I agree ... made a jab at it, but it's rather hard
(12:06:47) polio: My suggestion was to essentially remove FeatureResults (don't really see why it's needed)
(12:07:16) polio: also though a merging of FeatureIterator with FeatureReader was a good step
(12:07:32) cholmes: I like merging feature iterator with feature reader...
(12:07:34) polio: but one other question was "backwards compitibility"
(12:07:39) cholmes: FeatureResults I do need the getBounds
(12:07:51) cholmes: For gml production
(12:08:18) cholmes: But the main reason it was introduced was so people could get a FeatureCollection or a FeatureReader
(12:08:26) cholmes: To make it more backwards compatible.
(12:08:59) cholmes: As James is finally moving away from collections it looks like we can maybe get rid of that now.
(12:09:37) cholmes: And I think I can get around FeatureResults without a getBounds, I just need to keep a pointer to the FeatureSource so I can get at the optimized getBounds
(12:10:11) polio: yah, that was the idea (and you will want the back-pointer for featureType too)
(12:10:16) cholmes: But it could/would be nice for whatever FeatureIterator/reader construct we settle on to at least have a pointer to the FeatureSoure and the Query used to generate it
(12:10:21) jmacgill: A pointer to FeatureSource is a big one for me
(12:10:35) jmacgill: I need to be able to do operations on the set for which a feature belongs
(12:10:54) jmacgill: idealy I'd like the back pointer to be in the Feature (or perhaps in its FeatureType)
(12:11:32) polio: I have a concern with featureSource back-pointers, currently we use the FeatureReader as a minimum implementation to read data ... how would this affect our would-be implementators?
(12:12:31) cholmes: I think we should be able to provide abstract classes for them - I mean we do with DefaultFeatureResults - it stores the FeatureSource and the Query I'm pretty sure....
(12:12:33) polio: part of me wanted to leave that api 'as is' to allow for an easy first round of implementation
(12:12:59) cholmes: Which API?
(12:13:10) cholmes: Keep everything the same except deprecating readers/writers?
(12:13:12) polio: of, feartureReader/Writer
(12:13:54) cholmes: I'm fine with that, I like small incremental changes. But just keep it in mind, see what we can come up with to simplify things.
(12:13:55) polio: basically have some interfaces (hopefully distinct) for both sides of the glue code currently names Abstract*
(12:14:12) cholmes: Though we should address James's concerns, so he can move forward...
(12:14:27) cholmes: That sounds like it could be good (I'd have to see the code first though)
(12:15:42) polio: so I guess my point is that we should keep in mind what we want to ask people to write, and then not modify those interfaces with the back-pointers, but rather add the back-pointers (if we are, might find another solution as well) to other interfaces
(12:16:58) IanS ~en@dsl-179-179.dynamic-dsl.frii.net entered the room.
(12:17:10) cholmes: Sounds good to me.
(12:17:12) jmacgill: Hi Ian, good to see you
(12:17:21) IanS: arg, forgot about time change
(12:17:21) jmacgill: sounds good to me too
(12:18:04) jmacgill: polio can you put out some code examples for best practice for simple tasks?
(12:19:23) polio: if I think I understand correctly, you want an example FeatureReader?
(12:20:01) csdillard: I request code that demonstrates getting a DataStore, getting a FeatureStore from it, then writing a single new feature.
(12:20:24) jmacgill: yes, code for typical end users
(12:20:25) polio: (the easy implementation example would be GML datastore ... which only provides a feature reader)
(12:21:06) polio: chris, look into the WFSDatastore test cases for writing
(12:21:08) jmacgill: I'm not too woried (for now) about the inside of this. I need to see it from the end users perspective. Once I have that, the inside will make more sense
(12:21:19) cholmes: Oh yeah, my email did have one other concern - backwards compatibility, and if we want to follow normal conventions and have 2.1 work with 2.0
(12:21:34) cholmes: ...because it doesn't right now.
(12:22:25) polio: mm, that's a tough question (and rather political for me to answer)
(12:23:04) jmacgill: It is a little hard to see how it could. I'm more concerned that code written against 2.0 works with 2.1 (provided it used no depricated code)
(12:24:00) cholmes: Well, it could if we were conscious of changes, did good deprecations.
(12:24:14) cholmes: Though at this point we're pretty far down the path of incompatibility.
(12:24:50) ianT_ ~ian@spr2-leed1-5-0-cust234.seac.broadband.ntl.com entered the room.
(12:24:52) jpmeagher left the room.
(12:24:55) jmacgill: I agree, you know better than most, are we too far gone?
(12:25:19) cholmes: I've only just recently started working with 2.1.x, so I'm not sure yet.
(12:25:41) cholmes: The featureType getNameSpace() returning a URI instead of the string is what really kills me now.
(12:25:49) cholmes: It causes errors everywhere.
(12:26:02) csdillard left the room (quit: Remote closed the connection).
(12:26:04) cholmes: As they are compiled completely different, and it's such a core class.
(12:26:28) jmacgill: can we refactor that to getNameSpaceURI and depricate getNameSpace ?
(12:26:47) cholmes: That would be my suggestion.
(12:27:22) cholmes: At the very least it gets us out of the most egregious error in my mind, and then I can start to actually evaluate if the rest can be saved in some way.
(12:27:30) cholmes: polio, would that work for you?
(12:28:10) citizen_0 left the room (quit: Read error: 60 (Operation timed out)).
(12:28:39) polio: yup, works fine here
(12:29:19) cholmes: Cool, well let's start with that, and I can evaluate from there. I basically just want to be sure that we do care about backwards compatibility, that it's worth spending my time on.
(12:29:44) polio: who wants to work on this?
(12:29:52) polio: (the featuretype part)
(12:30:34) cholmes: I volunteer Jody (wink)
(12:30:41) jmacgill: can we split this up as specific JIRA tasks
(12:30:46) Martin___ ~Martin_De@rocher.ird.nc entered the room.
(12:31:40) polio: yah, but that just means me. I can help with some of it, but I'm not sure I have the time for the whole task
(12:31:42) cholmes: Split what up? The getNameSpaceURI stuff? That should be pretty basic, just needs one person to run through it all, no?
(12:32:20) polio: I could setup a featureType that will work ... but there may be some debuging (havn't seen the code)
(12:32:24) cholmes: I can probably spend a day on it if we schedule it, but my schedule right now is a bit uncertain, and full, as I'm traveling at the moment.
(12:32:43) polio: ok, lets make a bug and tag-team it
(12:33:03) cholmes: Ok
(12:36:53) polio: so, james can we ask you to draw up a plan for future api options w.r.t. backwards compatibility. Also we have a number of the requests I made which will both affect addtions (if they are not deleted) / subtractions / modifications
(12:37:17) polio: on the second note, perhaps we should look at the ones which are potential api additions and handle them first
(12:37:42) cholmes: Yeah, we really should have a more coherent policy as to backwards compatability, what developers need to observer
(12:38:17) jmacgill: indeed. we do have a depricate for one version policy, and changing tthe return type of a method clearly violates that
(12:39:36) jmacgill: I'm not sure I have a clear enough picutre of where we are and where we are going...
(12:39:58) jmacgill: I think perhaps we need a confuence page which we can all edit
(12:40:07) cholmes: sounds good
(12:40:12) polio: agreed
(12:40:23) jmacgill: and a set of JIRA issues for each proposed change
(12:40:26) polio: Ian(question) and comments?
(12:40:37) polio: *any
(12:41:23) ianT_: who me?
(12:41:41) jmacgill: ? = wildcard (smile)
(12:42:08) polio: either of you
(12:42:13) IanS: makes sense
(12:42:37) ianT_: As I forgot about the clocks changing and was thus an hour late I missed most of the question
(12:42:43) jmacgill: what happend to the R&D section of the website
(12:44:37) jmacgill: humm, page still exists, but no longer linked to from home page
(12:47:22) jmacgill: ok, what shall I call the page?
(12:47:57) jmacgill: DataStore clean up?
(12:48:30) polio: yah, but it's more the data package
(12:48:42) polio: "org.geotools.data assesment"
(12:50:19) jmacgill: http://docs.codehaus.org/display/GEOTOOLS/org.geotools.data+assesment
(12:50:33) polio: (smile)
(12:55:24) jmacgill: polio can you dump the contents of our email thread onto that page
(12:55:42) ianT_: can I make a quick plug for a mad idea we developed on the FreeGis list
(12:55:52) jmacgill: the book?
(12:55:56) ianT_: that what the world needs is a book on free gis
(12:55:59) ianT_: http://www.eogeo.org/Projects/projects_wiki/FreeGISBook
(12:56:04) ianT_: for more details
(12:56:14) polio: yah, can do