- what is up
- JP WFS Patches
- DataAccess proposal lasts too long
- OSGeo 2007 Report
jgarnett: cool; welcome to geotools and please stay for the IRC meeting.
jgarnett: which should be now ...
jgarnett has changed the topic to: IRC Meeting 0) what is up 1) JP WFS Patches
jgarnett: (change the topic to add agenda items; meeting last an hour)
groldan has changed the topic to: IRC Meeting 0) what is up 1) JP WFS Patches 2) DataAccess proposal lasts too long
***aaime did not have time to look at it today.... sigh
jgarnett: Hi aaime; anything for the meeting? And thanks for the 2.4.0 release (ahayes is here to talk about some of the WFS patches that were too slow to make it)
jgarnett: lol - hi gabriel; we will get it out of the way today.
jgarnett: that is the pain for working on the fun stuff; everyone wants a say.
groldan: aaime: no worries, may be you can take a look at the spikes while the meeting goes on?
aaime: I'll try
jgarnett: we got a new website (http://udig.refractions.net) - not worth an agenda item but still fun.
groldan: yeah, it'd be a pain not having your opinions
jdeolive: who here has decided on which option they prefer?
groldan: jgarnett: was lurking on it, nice stuff
jgarnett: well if that is it for agenda items we can start ... oh wait I got another one
jgarnett has changed the topic to: IRC Meeting 0) what is up 1) JP WFS Patches 2) DataAccess proposal lasts too long 4) OSGeo 2007 Report
groldan: (seems like you're foreseeing dataaccess to span for 2) and 3) )
jgarnett has changed the topic to: IRC Meeting 0) what is up 1) JP WFS Patches 2-3) DataAccess proposal lasts too long 4) OSGeo 2007 Report
groldan: l, lets move?
jgarnett has changed the topic to: IRC Meeting 0) what is up 1) JP WFS Patches 2) DataAccess proposal lasts too long 3) OSGeo 2007 Report
jgarnett: 0) what is up
desruisseaux: Martin: again on org.geotools.image.io.mosaic...
jgarnett: jgarnett - having fun with Eclisia; testing geoserver / udig; training materials; stressing out
Eclesia: johann sorel : new proposal : http://docs.codehaus.org/display/GEOTOOLS/Process+proposal
**sfarber is changing strategies about doing raster processing *inside the wms/wcs. Instead will do raster processing in-between the WCS/WMS and the client and not worry about having to create a specialized language in SLD/WCS for specifying raster-processing operations
***aaime is running like a crazy cat trying to do four things at a time
groldan left the room (quit: Nick collision from services.).
groldan email@example.com entered the room.
Eclesia is now known as JSorel
jgarnett: okay well that is what is up seems everyone is crazy
jgarnett: 1) JP WFS Patches
jgarnett: ahayes want to introduce yourself; and I will see if I can find that issue tracker number again
ahayes: Hi. I'm Amos Hayes. I manage the technical issues for a small research lab at Carleton University (http://gcrc.carleton.ca)
ahayes: We're developing an interactive atlas framework (http://nunaliit.org) that is designed to make it easier for people to add context and tell stories that include cartography.
groldan: cool, and you're needing the WFS plugin to get rock solid?
ahayes: Our main developer is Jean-Pierre Fiset who, due to a few boundaries we're pushing, seems to run across odd (or surprising) issues with GeoTools/GeoServer. We use GeoTools in our own server backend code as well as GeoServer as our WMS/WFS/WCS of choice.
jgarnett: Jean-Pierre showed up on IRC a couple days before 2.4.0 with a couple of bug fixes; looks like one of them missed the cut (http://jira.codehaus.org/browse/GEOT-1703). This is a case where lack of a WFS module maintainer hurt us; thanks to Gabriel for applying as much as he could before the release.
aaime: unfortunately wfs client issues are not... suprising... that module is dead in the water
ahayes: We're working on user contributed content features for Nunaliit at themoment, so WFS-T is getting some excersise.
aaime: ahayes, the issue here is that
jgarnett: I would like to review a few more patches and see if we can get JP svn access; but it would really help ahayes if he was hear to talk to us. We want to have confidence that he has read the developers guide and so on ...
aaime: to commit patches we need someone that understands the code (a mantainer)
aaime: we don't have a mantainer, so someone that does not understand the code but has commit access has to do the review
aaime: that is much more likely if JP is willing to become the new mantainer (that is, we have to make an effort to see if the patches make sense, but there is reward)
ahayes: Yep. So from what I can tell, he's been on and off IRC for at least a month trying to track down a few issues.
Jesse_Eichar firstname.lastname@example.org entered the room.
ahayes: Well I can certainly talk to him about that. I'm paying for his time so I'd have to have some idea of what that's going to cost me.
groldan: if they were to work with trunk it would be easier to get things going. As for the WFS module, the hard part is the old xml tech its using
groldan: that's what I guess is the most unmaintained part of it, and harder to maintain
simboss email@example.com entered the room.
jgarnett: Jesse and I are able to review; but we only care about 2.2.x and trunk
aaime: ahayes, how do you evaluate your cost? It's not like we ask any fee for assisting JP
aaime: (at least if we get a mantainer in exchange )
aaime: alternatively you can come up with a list of things you want to get fixed and pay someone of the official developers to fix them
ahayes: Hmm.. So that has been a big issue for him. He has been pointed to a few different branches in his attempts and in some cases, he's had to patch 2.2, 2.4 and trunk depending on that features we needed and what was broken where.
aaime: but that would not be nearly as good as getting someone new on the module
simboss: (hi guys, sorry I am late but gotta go back in shape, summer is approaching )
aaime: why so?
aaime: I mean, why that many branches?
avc_afk is now known as avc_nice
jgarnett: filter visitor aaime; your fav bit of undone work.
aaime: jgarnet, I'm not following you
ahayes: Because each seems to have stuff that works, and other stuff that doesn't. Every time he switched branches, something started working and something else broke.
ahayes: I wish he were here today and could comment, but I will get him in here soon to explain himself.
jgarnett: sending requests to WFSDataStore depends on the pre/post filter visitor code; that was never really QAed after the change to geoapi filters. JP is coming along and finding these problems; I helped him through a patch last week - but there is more pain before this is going to get better.
cholmes: ahayes, the best from our perspective would be to work on trunk. Gabriel's got some funded time to work on WFS, and any fixes made to trunk we only have to apply once...
cholmes: Fixes made to older branches will get lost or else need extra time to move forward.
cholmes: That said, trunk can be scarier...
aaime: trunk is the place for new developments
aaime: so it's not nearly as stable as other branches
cholmes: but GeoServer trunk is now living on geotools trunk, which we've not always done, and it's been helping to make it more stable.
ahayes: I think if he were going to jump in and help maintain, then he'd be on trunk. But as product developers ourselves, we wanted to be able to point at a versioned GeoTools for patches, etc. We need some stability.
jgarnett: udig trunk is also there; running full tilt into the same problems JP is finding.
aaime: ahayes, you can develop patches on trunk and then backport them
aaime: that's what we do for GeoServer
groldan: actually, if JP were working on trunk he could start moving WFS 1.0 DataStore to share more code with the 1.1 flavor I'm working on and thus get rid of a ton of pending issues with the old parsers, at the cost of dealing with the new ones, but in the end having a stady approach for both
ahayes: Unfortunately, we have our own app to build and that's where his focus needs to be.
jgarnett: as you can see you have found a "hot topic" for development. We would love to work with JP on this stuff; if you would like to figure out the extent of your involvement that would be great. At the very least it would be good to move towards svn access so we are not a bottle neck.
avc_nice is now known as avc_mean
jgarnett: I am sure that is a lot to think about; did you have any additional questions.
ahayes: I think I could afford some time for him to help and get patches on trunk as things move along, but we can't afford to have him take on whole new things. We're running from grant to grant here.
aaime: which is exactly the reason why wfs client is unmantained
groldan: though getting svn access for a two-week patches is equally scaring, that's why we require patches first, and patches with unit tests to have more options to be taken rapidly
aaime: there was money to create it
aaime: but not for long term mantaininace
ahayes: No. That helps a lot. I will make sure he's read the process docs (I'm pretty sure he has) and I'll get him to keep submitting patches (against trunk? 2.4? both?) for the problems he hits.
aaime: ahayes, both
jgarnett: moving on.
jgarnett: 2. Data Access proposal
jgarnett: groldan go!
groldan: here we go
***jdeolive fastens his seatbelt
groldan: imho we have only two options: generics and nogenerics
***aaime desperately tries to read the code
groldan: the middle ground solutions sucks
groldan: and since I hope the requirements are clear
groldan: it'd be time to know who already has a strong inclination towards one of them
groldan: aaime hint: face to the Example.java class in org.geotools.data.sample package
jgarnett: middle ground is the same as generics (with a few subclasses so that new users do not get scared) - it does not completly suck.
jgarnett: generics +1
jgarnett: middle ground +0
jgarnett: nogenerics +0
aaime: wow you replicated the whole api module
aaime: there is no way I'll be able to do a 5 minutes review
jgarnett: in all three cases.
groldan: jgarnett: right, I meant the parametrize only the arguments one, that one sucks, though not even in spike
aaime: jgarnett, I need half a day to have a look at all this stuff...
jgarnett: aaime; focus on DataStore getFeatureReader method to see the approaches in a nutshell.
avc_mean: groldan, why not just do the one you prefer?
groldan: because that's not how I've been told this works
avc_mean: since we don't have any really good analysis for you
groldan: (though I was hoping nobody replies in three days so I was free to go )
avc_mean: jgarnett: groldan go!
jgarnett: I like the generics approach because there is less stuff at the end of the day to document and understand; but I recognize that I like generics and am pretty good at reading them now. The middle ground approach where the generics is hidden for the common case may actually represent the best solutions. Question for me comes down to how much to cater to new java developers.
jgarnett: Answer: Generics is part of Java 5; lets update our API and take the benifit of not needing extra classes since the compiler will sort out the details.
aaime: sorry, am I looking at the wrong samples? I don't see the org.geotools.data.sample in jdeolive one?
jdeolive: aaime: i created a seperate module called example
jgarnett: gabriel - do the one you prefer; you are the guy doing the work. What do you think!
aaime: or they are not meant to be 1-1 comparable?
jdeolive: to my defense i was the firs tone who did it so it was others who did not follow suit
aaime: I wasn't trying to blame anyone
avc_mean: go generics go!
aaime: just trying to figure out how to compare the code
groldan: the generics one also does not put us on naming hell
groldan: and it seems all name schemes we tried sucked
avc_mean: FeatureSource was the piece I found most comparable if i remember right
jgarnett: or limits naming hell to once class; the super class
jgarnett: avc_mean - you are correct; except that it was not completly done (the visitor and add features methods were sometimes out of wack). getFeatureReader was the better test.
avc_mean is now known as acuster
desruisseaux: (my point may not be relevant since I'm not very familiar with the two proposal, but I'm of course all for generic)
Jesse_Eichar: I'd probably go for generics. But I'm also not a good candidate since I've been using generics for years
jgarnett: your input helps martin. don't worry.
aaime: it's a pity that we need to parametrize like this: FeatureWriter<SimpleFeatureType,SimpleFeature>
aaime: since one parameter logically implies the other (logically, but not in practice....)
groldan: thing is easy: generics sort of means yeah, we're moving to java5. The others has great value too, but its time to compromise (ie, sure with every choice you'll be losing something)
Jesse_Eichar: Do you think it is a good API for beginners to generics as well?
groldan: beginners are programmers
jgarnett: going with generics is not a clear loss for beginnersthere is less classes to understand with generics and that means a lot when starting out.
acuster: it's not terribly complex
desruisseaux: For beginner (as well as for anyone actually), it help to prevent bugs.
jgarnett: even with the generic approach there is a clear subclasss (ie DataStore) for the most common case.
desruisseaux: If beginner are more likely to do bug, it has yet more value for beginners.
***jdeolive thinks we should leave the generic debate until later
jdeolive: and just state ones preference
simboss: a simple naive questions
jdeolive: and not why
simboss: isn't this implementation of store a little bit feature centric with respect to what we said last time?
simboss: and source as well
groldan: simboss: yes it is, we're running out of time and including coverage is a scope bomb for this run, though I'd be glad to get involved if you want to bring it later
simboss: source to me should data type agnostic
aaime: didn't we agree that coverage "stores" would have better been isolated in their own hiearchy?
jgarnett: simboss the idea was to set a common approach; you will find your proposal page is similar.
jdeolive: aaime: i know i did
simboss: that's what you suggested aaime
jgarnett: but I needed help defining the Query before throwing it into the ring.
aaime: Ah, I see
jdeolive: as groldan says... this is someone off topic at the moment
jdeolive: if we start talkign about coverages this proposal will never reach resolution
simboss: I am not asking to stop anything jdeolive
simboss: but from a user perspective
simboss: because I am just a user of the feature part of geotools
jdeolive: simboss: sorry, i mis understood, i thought you are were asking about coverages
simboss: this split generates some confusion for me
simboss: because I see source
simboss: or store
simboss: as something not feature bound
jdeolive: simboss: right... but keep in mind that is only one of the alternatives
acuster: a coverage is a feature but a gridcoverage is not, so when we get real coverages things will work the same way
simboss: lets say I would expect
simboss: so I was just exposing a thought
simboss: this naming looks ambiguos to me
simboss: to make a long story short
jdeolive: same to me... which is why that is not my choice
acuster: groldan, do you need a vote?
groldan: we could even be more rude and rename the current FeatureSource as SimpleFeatureSource and so on so we have a consistent naming scheme
aaime: in theory the generics approach looks cleaner... but I'm finding very hard to accept the double parametrization spreading in the client code
groldan: but goes quite against the as backwards compatible as possible idea
jdeolive: aaime: keep on thing in mind
jdeolive: that if you write code against Feature you dont have to parameterize
groldan: aaime: I don't see how to solve that without a layer of indirection
groldan: (like the crazy idea of parametrizing just Query)
aaime: jdeolive, yes, but feature interface is designed to be slow
aaime: there is no way you can make fast code if you're forced to go thru an hashmap like lookup
jdeolive: ok... so far jody has voted +1 for generics
jdeolive: am i correct jgarnett ?
jdeolive: and so has martin
jgarnett: you are totally correct; I think the other approaches are capable - but the generics has less code - and I think that is a win all around. For begginers as well.
jgarnett: For details (like the name of the superclass we can leave that to gabriel).
jdeolive: aaime: another thing to keep in mind is that you can simply cast and put up witha compiler warning if you dont lie the look of declaring parametrized variables
jdeolive: ok... groldan have you made up your mind?
jgarnett: guys we are over our timeslot; I don't really want to waste meeting time while andrea reviews the proposals for the first time.
jgarnett: can we hit our last topic; or vote and move on.
groldan: I'm for generics, so if no pmc has a -1 I guess we got it
jdeolive: ok... so its simboss and aaime remaining
jdeolive: letrs give them more time to review
aaime: I equally satisfied/dissatisfied by both approaches
JSorel: (vote generic, for the beginner i am)
jdeolive: aaime: so 0 ?
simboss: guys I don't want to block anyone's work here
aaime: If there was a way to have a single parameter I would vote for generics me too
aaime: like this, 0, yes
simboss: ( I prefer generics anyway )
jgarnett: simboss; did you look at the http://docs.codehaus.org/display/GEOTOOLS/GridAccess+based+on+WCS+Specification - I lined it up with these proposals pending your feedback.
groldan: aaime: 0 for all three approaches, right?
jdeolive: ok... so it seems we are more or less decided
aaime: nope, -1 for the hybrid
simboss: jgarnet: I started to convert them on classes and I am playing with it
acuster is now known as avc_mean
groldan: that's not even an option, I'll update the proposal page
simboss: jgarnet: but it's not the first one in the queue
jgarnett: wow - that is sweet simone
jgarnett: 3) OSGeo Report
jgarnett: Sent out an email a while back
jgarnett: the deadline is now on us.
simboss: groldan: all I suggested was, can we use a name that may allow us to derive a separate hierarchy for coverage I/O?
jgarnett: is there anything we want to add?
jgarnett: Like looking for a WFS module maintainer ...
simboss: groldan: store and source should not imply feature IMHO
groldan: simboss: seems fine, as we took the one with least new classes seems like we don't use Source
groldan: and the line
groldan: they won't exist as per the approach taken
avc_mean: Geotools is ready!? cough
markusin_ left the room (quit: Connection timed out).
groldan: so they can be worked out in the future, sounds good?
simboss: groldan: k
jgarnett: lol; you try and write something motivational!
avc_mean: you won't be bored on geotools trunk!
jgarnett: that sounds good.
CIA-1: desruisseaux * r29189 geotools/gt/modules/ (3 files in 2 dirs): More opportunist tiles creation in MosaicImageWriter (i.e. leverage already loaded images). Consolidation in TileBuilder.
avc_mean: oh, talk about JSorel more!
JSorel is now known as Eclesia
avc_mean: he's been doing fun stuff last year
sfarber left the room.
jgarnett: how about: GeoTools is looking forward to making 2008 the best year yet. There is lots of exciting development now underway - from embracing Java 5, to rolling our WFS 1.1 support. 2008 will see the long expected return of swing widgets to the GeoTools library.
avc_mean is now known as acuster
jgarnett: seriously I have no interst in this page; I only wrote something so we did not look like idiots; please hack away - it goes out this week.
***acuster has no interest in the page either. it looks like english
acuster: do we have to do one every year?
acuster: well thanks for doing it then
jgarnett: okay meeting is done? Sorry for letting it go over time.
jgarnett: I will post the logs