[15:07] <aaime> Hi all
[15:07] <aaime> meeting time?
[15:07] <groldan> hi, yes
[15:09] <iwillig> arneke: which jars
[15:09] <-- tschaub has left this server.
[15:10] <dwinslow> hi aaime
[15:11] <aaime> topics you want to discuss?
[15:12] <groldan> 1) geoserver trunk goes generics?
[15:13] *** aaime sets the channel topic to "0) What's up 1) GeoServer trunk goes generics?".
[15:14] <aaime> anything else?
[15:14] <groldan> seems not  much
[15:15] <groldan> go on?
[15:15] <aaime> Maybe we'll come up with other topics during the meeting
[15:15] <aaime> let's start
[15:16] <aaime> 0) What's up
[15:16] * jdeolive is working on workshop materials for GSDI
[15:16] * aaime fixing 1.6.1 related bugs and committing stuff that has been sitting on my disk for too much time
[15:17] * groldan is working on implementing the dataaccess proposal in geotools
[15:18] * dwinslow working on RESTConfig rearrangement and security
[15:18] <afabiani> afabiani is working on RS proposal
[15:19] <groldan> go alessio go!
[15:19] --> vheurteaux has joined this channel (n=vheurtea@AMarseille-153-1-9-65.w86-194.abo.wanadoo.fr).
[15:19] <afabiani>
[15:20] --> bmmpxf has joined this channel (n=mike@cpe-66-108-80-238.nyc.res.rr.com).
[15:20] <aaime> Shall we move to the next topic?
[15:20] <groldan> yup
[15:20] <aaime> 1) GeoServer trunk goes generics?
[15:20] <aaime> Gabriel?
[15:21] <groldan> k, as trunk is against gt trunk, and gt trunk goes generics for the data access api...
[15:21] <groldan> I guess I'll have to update geoserver accordingly
[15:21] <groldan> right?
[15:21] <aaime> I guess so, yes
[15:21] <bmmpxf> Hello all.  I'm Mike, new at TOPP, new to GeoServer, but listening intently and trying to get up to speed...
[15:21] <aaime> Welcome
[15:21] <groldan> so I think that'll happen over the end of the week
[15:21] <jdeolive> bmmpxf: hi mike
[15:22] <groldan> if there's no objections
[15:22] <aaime> I guess it's inevitable, given that we approved the gt2 proposal?
[15:22] <groldan> not it _only_ means updating the DataStore api usage to adapt to generics so geoserver does not break
[15:23] <groldan> it does not mean any sort of introduction for complex feature support so far
[15:23] <jdeolive> groldan: i have a question
[15:23] <groldan> shoot
[15:23] <jdeolive> what is the preffered code style when porting to generics
[15:23] <groldan> (not it _only_ --> note it _only_)
[15:23] <jdeolive> to declare teh variable as a generic, or to cast the resulting feature?
[15:23] <jdeolive> what do people prefer?
[15:24] <groldan> don't know what people prefer, but its easier to declare de variable with generics imho
[15:24] <aaime> Declare as a generic required that double param on readers, right?
[15:24] <groldan> bmmpxf: welcome! btw, sorry didn't read you before
[15:24] <aaime> anyways yes, I guess, if we adopt generics, let's do it for good
[15:24] <jdeolive> correct
[15:24] <aaime> groldan++
[15:25] <jdeolive> works for me
[15:25] <groldan> k, so that's more or less it is, if no objections I'll have to do it over the end of the week once I commit the geotools changes
[15:25] <groldan> so you're warned
[15:26] <groldan> and as we move to java5 and Feature, geotools should be called 3.0 and geoserver 2.0, but that's worth another topic
[15:26] * jdeolive snickers at aaime
[15:26] *** fatgoose is now known as samuel.
[15:27] <groldan> do you think that's a big enough change as to do that? it certainly would make sense imho
[15:27] <jdeolive> groldan: aaime and myself had a little chat abotu what we thougth a geotools 3.0 should look like
[15:27] <jdeolive> which is why i snicker
[15:27] <jdeolive> but as you say, that is another (ratehr large) topic
[15:27] <groldan> yup, I realize that
[15:27] <groldan> one that we should have at some time though
[15:27] <jdeolive> groldan: i dont think we should call it 2.0
[15:28] <jdeolive> since our users see no changes
[15:28] <jdeolive> except maybe a few bugs
[15:28] <jdeolive> wether its geotools 3.0... i cant really say
[15:28] <groldan> yeah, makes sense
[15:28] <aaime> geoserver 2.0 will be something that breaks
[15:28] <jdeolive> plus i think we are saving 2.0 in order to break data dir backwards compatability
[15:28] <aaime> backwards compatibility
[15:28] <aaime> yep
[15:28] --> tschaub has joined this channel (n=tschaub@host-69-144-84-214.bzm-mt.client.bresnan.net).
[15:29] <groldan> k, agreed from the geoserver perspective, didn't thought much about it so glad you already did
[15:30] <groldan> do you think we should raise the topic at next geotools meeting?
[15:30] <jdeolive> sounds good
[15:30] <aaime> yep
[15:31] <groldan> one thing that didn't came up with your spike, though
[15:31] <groldan> is that FeatureSource.getDataStore now has to either be casted to DataStore
[15:31] <groldan> or a new method is needed and getDataStore should be deprecated
[15:32] <groldan> like it can't return DataStore out of the box, but DataAccess<T, F>
[15:32] <aaime> right...
[15:32] <-- vheurteaux has left this server.
[15:32] <jdeolive> right...
[15:32] <aaime> lol
[15:32] <jdeolive>
[15:32] <groldan> so all code that does DataStore ds = fs.getDataStore() needs to be changed to DataStore ds = (DataStore)fs.getDataStore()
[15:33] <groldan> I'm fine with it
[15:33] <groldan> rather than a new method, do you?
[15:33] <aaime> I don't see a way out since we avoided inheritance
[15:33] <aaime> no please, no new methods
[15:33] <groldan> cool so
[15:33] <aaime> going backwards from FeatureSource to DataStore should not be that common in the code
[15:34] <groldan> well, we do have new methods
[15:34] <groldan> from AbstractDataStore as an example: http://pastebin.com/m192d6737
[15:34] <sigq> Title: pastebin - collaborative debugging tool (at pastebin.com)
[15:35] <aaime> groldan, I meant, avoid new methods just for the sake of avoiding a cast
[15:36] <groldan> and FeatureSource.getName():Name, that's quite it
[15:36] <groldan> aaime: sure thing
[15:37] <groldan> seems like we're done
[15:37] <aaime> yep, it seems so
[15:37] <aaime> btw, I have more than 50% of the 1.6.1 issues assigned to me
[15:38] <aaime> anyone willing to grab some?
[15:38] <aaime> (that's the result of being the default issue target)
[15:38] <aaime> there are quite a bit that sound like 20 minutes work
[15:38] <groldan> I would love to, long time since I don't do real gs work, though not sure how I'll be over the next weeks
[15:39] <groldan> ok, I may be able to take a couple 20 mins worth ones
[15:39] <aaime> pick up whatever you prefer, I won't complain
[15:40] <aaime> I've tried to start with the biggest, more complex ones so that they get a good shake before release
[15:40] <aaime> the only one really really big is watermarking afaik
[15:41] <groldan> cool, about the maxFeatures stuff, do we make it spec compliant right?
[15:41] <aaime> Yeah, thought I did not hear back from C. Tweedie so I kept the issue open
[15:42] <aaime> jdeolive
[15:42] <aaime> I think I already fidex  http://jira.codehaus.org/browse/GEOS-1618 ?
[15:42] <sigq> Title: [#GEOS-1618] pass describe feature type cite tests - jira.codehaus.org (at jira.codehaus.org)
[15:42] <aaime> (fidex -> fixed)
[15:42] <jdeolive> you did?
[15:42] <jdeolive> how?
[15:42] <sfarber> aaime:  have you co-ordinated with simboss and afabiani about the watermarking stuff coming from 2.4.x_rs?
[15:42] <groldan> I'm not sure if I was missing something, but looked to me that if he wants results=hits to return the actual query results, should just not include a maxFeatures param
[15:43] <aaime> groldan, he's talking about the maxFeatures configured in the feature type there
[15:43] <aaime> (in the feature type and the global one as well)
[15:43] <aaime> jdeolive, by changing a schema.xml file
[15:43] <aaime> I did send a mail about it
[15:44] <jdeolive> aaime: right, i remember now...
[15:44] <groldan> k, that's the other issue, that I call server limit. So yeah, it should return the server limit if its lower than the query result
[15:44] <jdeolive> aaime: i thought schema.xml was unused ... i guess not
[15:44] * jdeolive thinks he might be losing his marbles
[15:44] <aaime> whatever is the name for wfs 1.0
[15:45] <aaime> (schema.xml is for wfs 1.1 right? anyways, there's a name for wfs 1.0 as well)
[15:45] <aaime> groldan, correct
[15:45] <aaime> and Tweedie wanted a different behaviour
[15:45] <aaime> see my last comment on that jira
[15:45] <jdeolive> aaime: i thought it was schema.xsd for wfs 1.1, i thought schema.xml was just used for the ui
[15:46] <aaime> hum, no, in fact it's used also by the feature type setup code
[15:46] <jdeolive> ahh ok
[15:51] <aaime> anyone ponsting the logs?
[15:51] <aaime> sfarber, yes, I did
[15:51] <sfarber> aaime:  cool.  glad to hear it.
[15:51] <aaime> I just have to find the time and review Alessio's patch
[15:52] <aaime> crazy times, I work like mad and at the end of the day I feel like I did nothing
[15:53] <Pitr> create todo-lists and take good time out of ticking off items at the end of the day
[15:53] <aaime> heh, right
[15:53] <Pitr> that way your perception will keep up with reality
[15:53] <jdeolive> aaime: question for you
[15:53] <aaime> shoot
[15:53] <jdeolive> security and storing passwords
[15:53] <jdeolive> clear text only at the moment correct?
[15:53] <aaime> unfortunately yes
[15:53] <aaime> gimme a U
[15:54] <aaime> gimme a I
[15:54] <aaime> gimme a UI!!!
[15:54] <jdeolive> haha
[15:54] <jdeolive> also
[15:54] <jdeolive> where does the file end up with the passwords in it?
[15:54] <aaime> data directory
[15:54] <groldan> (save the cheerleader, save the world)
[15:54] <jdeolive> under security
[15:54] <jdeolive> groldan: lol
[15:54] <aaime> yes, users.properties
[15:54] <aaime> ha ha
[15:54] <jdeolive> cool, thanks aaime
[15:55] <aaime> guys, I'm going
[15:55] <aaime> anyone posting the logs?
[15:55] <groldan> can do
[15:55] <aaime> nice
[15:56] <aaime> bye all!