05 <gabriel> ping
05 <gabriel> it seems we don't have a lot of attention for the breakout
05 <gabriel> hopefully much was discussed at the ml
06 <gabriel> so I had a run over the hierarchy+generics approach
06 <gabriel> http://docs.codehaus.org/display/GEOTOOLS/Dry+Run+at+DataAccess+Story
06 <gabriel> it seems the cleaner so far, as it does not imposes extra grief to the current interfaces
07 <gabriel> made some void implementations of those interfaces and all seems right
07 <aaime> looking
07 <gabriel> it'd be nice if you could take a look at it while I hunt for a couple more attendees?
07 <aaime> ugh, long page
07 <gabriel> that's why its a child of the proposal one 
09 <aaime> looking at this:
09 <aaime> SimpleFeatureType getSchema(String typeName) throws IOException;
10 <gabriel> right, mistake
10 <aaime> does not seem to narrow down, but to overload instead?
10 <gabriel> fixed
11 <gabriel> no, type narrows cause the argument is Name
11 <gabriel> it was a copy&paste mistake
11 <gabriel> refresh
11 --> dwinslow has joined this channel (n=david@cpe-66-108-80-238.nyc.res.rr.com).
11 <aaime> Name -> String is not type narrowing?
11 <aaime> they are not in the same hiearchy?
11 <aaime> (what I am missing?)
12 <aaime> Ah, got it
12 <gabriel> k
12 <aaime> but then we need the overload as well to keep
12 <aaime> the api compatible right?
12 <gabriel> for that case yes
12 <gabriel> we need Name for complex to work propoerly
12 <aaime> but we need String to be backwards compatible
13 <aaime> so we need both
13 <gabriel> yup
14 <aaime> I really wish there was a way to have classes have just one parameter (the type of feature)
14 <aaime> instead of the collection and reader type
14 <aaime> that seems .... odd
14 <gabriel> agreed
14 <gabriel> yet I don't know how
14 <aaime> we would need to make reader and feature collection parametric as well I guess?
15 <aaime> Reader<T extends Feature>
15 <aaime> FeatureCollection<T extends Feature>
15 <aaime> or something like that?
15 <gabriel> I don't think so
15 <gabriel> reader can just type narrow the return type
15 <aaime> so?
16 <gabriel> otherwise we can rather parametrize FeatureReader and get rid of its super type
16 <gabriel> it'd work for me too
16 <aaime> btw, you did not define ComplexFeatureReader anywhere?
17 <gabriel> right, gonna add it
17 --> jgarnett has joined this channel (n=Jody@mail.refractions.net).
17 <aaime> tsk tsk, you're late 
18 <gabriel> aaime: done
18 <gabriel> oops, lacks extends
19 <gabriel> k, now for good
19 <gabriel> hi jgarnett
19 <jgarnett> hello
19 <gabriel> we're taking a look at the parametrized approach
19 <gabriel> http://docs.codehaus.org/display/GEOTOOLS/Dry+Run+at+DataAccess+Story
19 <gabriel> wanna join?
19 <jgarnett> sorry I am slow; Paul is setting up an improved uDig confluence :-D yeah!
20 <gabriel> cool!
20 <jgarnett> (actually confluence has improved a lot; maybe we should host one on osgeo hardware rather than codehaus)
20 <aaime> So, would it be possible to have FeatureReader<F extends Feature, T extends FeatureType>?
20 <gabriel> andrea would like to have to parametrize by <F extends Feature, T extends FeatureType>
20 <gabriel> me too
20 <gabriel> just not sure how?
20 <gabriel> I guess you know more generics than me
20 <aaime> not me
21 <jgarnett> beso which one of the alternatives is represented on this page? Minimal generics for parameter objects?
21 <aaime> And we could have Feature collection based on the same parameters
21 <aaime> jgarnett, I was saying that
21 <gabriel> aaime: sounds good to me, if we agree to insert parametrized at the current api
21 <aaime> parametrizing over feature collection and feature reader
21 <aaime> seems odd, clunky
22 <jgarnett> nope it looks like you guys are using generics for return values as well; not sure that is needed...
22 <aaime> I'd prefer to see parameters like the feature and feature type you're using
22 <jgarnett> opps I will shut up and listen for a bit.
22 <aaime> jgarnett has a point here
22 <gabriel> so yeah, this one is minimal parametizing to narrow parameters
22 <gabriel> jgarnett: for the sake it was the same, we can change return parameters to type narrow
23 <gabriel> soooo
23 <jgarnett> how so? ComplexFeatureSource<F, R> is more complex then needed; all you need is ComplexFeatureSource<Q>
23 <aaime> right, I'm not seeing params being used in the method params, but only in the return types?
23 <gabriel> if we're ok in inserting parameters on the current API (DataStore, FeatureSource, FeatureStore)
23 <gabriel> I can give a try to it
23 <gabriel> it'd be still cleaner
23 <aaime> jdeolive wanted an approach that only used one class instead of a hiearchy, or I'm missing something?
24 <gabriel> and don't think it'd be too much a grief for users upgrading from 2.4 to 2.5?
24 <jgarnett> I think we better call this 3.0 honestly; changing data model (done) and now data access ...
24 <jgarnett> it is a 3.x change....
24 <gabriel> aaime: you're right, but that does not buys us goal number 2
25 --> pramsey has joined this channel (n=pramsey@mail.refractions.net).
25 <gabriel> "We want current code to keep backwards compatible. This means the library won't break all the code written with the SimpleFeature assumptions. And we want all the format drivers written in simple terms to be used as the more general Feature/Type out of the box."
25 <gabriel> I asked for agreement on that before going forward
25 <aaime> ah right
26 <jgarnett> yep; so at a minimum we need one super class each for DataStore, FeatureSource, FeatureStore, FeatureLocking
26 <gabriel> so, minimal type hierarchy + parametrized collection and reader would buy us enough simplicity and flexibility?
26 <jgarnett> I was wondering if we could use FeatureReader<F,FT> and save some pain?
26 <gabriel> yeah, that's what I'm asking
26 <gabriel> putting the burden on upgrading code
27 <gabriel> I'm fine with it
27 <jdeolive> hi guys, sorry i am late
27 <aaime> Hey
27 * jdeolive is catching up
27 <jgarnett> even so that is a small question: FeatureReader<F,FT> vs (Reader and FeatureReader)
27 <gabriel> not that a burden though, they may just need a couple supresswarnings
27 <jgarnett> I am way more interested in Query ...
28 <aaime> so you see no way to simplify that ugly set of params?
28 <aaime> if so, how would the interfaces change?
28 <jgarnett> I do ... we only use generics for the Param objects
28 <jgarnett> I will make a page and modify the code example ...
28 <gabriel> like in Query.getPropertyNames():String[]?
28 <aaime> thanks, that would help
29 <jgarnett> based on email yesterday I was hoping someone else would give it a try ... I did one example on email.
29 <jdeolive> i would up for taking a shot at it
30 <jdeolive> i am not convinced we need a subclass for each of those
30 <jdeolive> but i admit... until i look at it i dont really know
30 <jdeolive> so is this a formal meeting? is someone driving?
30 <-- pramsey has left this server.
31 <gabriel> jdeolive:
31 --> pramsey has joined this channel (n=pramsey@mail.refractions.net).
31 <aaime> jgarnett, I've been fighting to get 2.4.0 in a releasable state, I did have no time
31 <aaime> jdeolive, not so far, everybody just popped up now
31 <gabriel> there are assumptions over simplefeature we need to get rid of for the general case
31 <jdeolive> right
32 <jdeolive> so to keep things clear here
32 <jdeolive> can we come up with an agenda
32 <gabriel> there are compelling forces all over the way
32 <jdeolive> and work through the issues
32 <jdeolive> does that make sense?
32 <gabriel> in order to get the whole picture we need to keep in mind the main goals
32 <aaime> jdeolive++
32 <jdeolive> cool, i am happy to drive
32 <-- pramsey has left this server (Read error: 104 (Connection reset by peer)).
33 <gabriel> we first agreed on the goals then the proposal comes through, changing scope may lead to a different situation
33 *** aaime sets the channel topic to "1) main goals".
33 <jdeolive> so as per gabriel's suggestion, why dont we nail down what the main goals are
33 --> pramsey has joined this channel (n=pramsey@mail.refractions.net).
33 <gabriel> ie, it may be possible to not introduce a type hierarchy if we want to break the api and remove a lot of stuff
33 <gabriel> they're on the page
33 <jdeolive> link?
33 <gabriel> http://docs.codehaus.org/display/GEOTOOLS/Dry+Run+at+DataAccess+Story
34 <gabriel> basically 2, the first is easy, the second is the one forcing us to take a compromise
34 <aaime> So to sum up
34 <aaime> 1) Use Name to keep namespaces around 2) Make the change backwards compatible
35 <aaime> anything else?
35 <gabriel> yep
35 --> cholmes has joined this channel (n=cholmes@cpe-66-108-80-238.nyc.res.rr.com).
35 <gabriel> and allow to ask the factory system to return DataStores as they're now (simplefeature) or anything that works with Feature
35 <aaime> jdeolive, jgarnett, do we have an agreement on the principles at least?
35 <gabriel> that falls on backwards compatible
36 <gabriel> but the use case is worth to be mentioned
36 <jdeolive> aaime: yes
36 <jgarnett> sorry writing right now; will be back in a moment.
36 <gabriel> a smooth upgrade path for the code that cares to upgrade to Feature, backwards compatibility for the code the doesnt, and out of the box functionality for new code
37 <jgarnett> the above two principles seem fine; (2) == no casting for Simple case
37 <jdeolive> well put jody
37 <jgarnett> 3) don't screw over the Feature / FeatureType case as well
37 <gabriel> if it were just a matter of casting
37 <gabriel> think of udig and geoserver as they're right now
37 <aaime> jgarnett, what does that mean?
38 <jgarnett> even if it is just a matter of casting gabriel; you would do well to introduce a specifc subclass so end users don't have to.
38 <jgarnett> the difference betwee: Reader<SimpleFeature> and FeatureReader extends Reader<SimpleFeature>
39 <jgarnett> (it is not worth our time to watch users be confused)
39 <jgarnett> aaime - does that explain what I mean ?
39 <jdeolive> jgarnett: lets not make assumptions about users until we have a better idea of what the api will look like
39 <jgarnett> okay; I can handle that ...
39 <jdeolive> we made that mistake with featurecollection and look what happened
39 <jgarnett> proceed!
39 <gabriel> jdeolive: users == working code
39 <gabriel> we're a library
40 <jdeolive> i am not sure what that means but ok
40 <jdeolive> so it sounds like we have a good idea of what we want
40 <jdeolive> not we need to nail down how we get it
40 <gabriel> that means that if I want to upgrade my app to use geotools 2.5 is should just work
40 <jdeolive> so it seems gabriel has come up with a first cut on that page he just sent out?
40 <gabriel> as we do with other libraries (junit4 the most recent case)
41 * jdeolive thought that backwards compatability went without saying
41 <jdeolive> but yeah, i agree
42 <aaime> Ok, so, we agree on the general principles, what now?
42 <jdeolive> i would say
42 <gabriel> so, as I see it. parametrizing collection and reader would still get client code working
42 <jdeolive> gabriel: i agree
42 <jdeolive> they may get warnings but not errors
42 <jdeolive> afaikl
42 <aaime> jdeolive, gabriel
42 <gabriel> and we should only need the superinterfaces for datastore, source, store, locking
43 <aaime> am I the only one finding collection and reader as the type parametres
43 <aaime> odd?
43 <jdeolive> gabriel: that part i am not 100% convined on
43 <gabriel> aaime: agreed very odd
43 <jdeolive> aaime: yeah i agree i dont quite get that
43 <gabriel> just at the time of writing we still didn't agreed on parametrizing existing interfaces
43 <jdeolive> i woudl think that just Feature and FeatureTYpe would be he parameters
43 <jdeolive> and everything else works by just parameterting them
43 <jdeolive> gabriel: ok.. so that code example is out of date?
44 <gabriel> cool, I like that much better too
44 <gabriel> indeed
44 <jdeolive> cool
44 <gabriel> I can remake it for the new agreement
44 <gabriel> and call for voting?
44 <jdeolive> sounds good to me, so lets make sure that everyone understands the srategy first
44 <gabriel> yet, though not an immediate need of mine
44 <jdeolive> shall i take a shot at summing it up?
45 <gabriel> we'll have to keep an eye on the need for:
45 <gabriel> namespace aware filters
45 <gabriel> sure
45 <jdeolive> ok so the way i see it is this
46 <jdeolive> we add Feature and FeatureType parameters to basically all of our data access classes
46 <jdeolive> DataStore, FeatureSource/Store, FeatureReader/FeatureWriter
46 <jdeolive> we can do that without subclassing correct?
46 <gabriel> yup
46 <jdeolive> sorry
46 <jdeolive> ok
46 <jdeolive> and now there is the problem of backward compat
46 <gabriel> still can't get only simple feature capable datastores out of the factory system
46 <gabriel> right
46 <jdeolive> so
47 <jdeolive> we coudl creeate a super class for DataStore
47 <jdeolive> and have DataStore narrow all the paramaters for hte other classes
47 <jdeolive> to SimpleFeature and SimpleFeatureType
47 <jdeolive> in theory that should keep things backwards compatable
48 <jdeolive> although i guess not
48 <jdeolive> users who did this:
48 <jdeolive> FeatureSource = dataStore.getFeatureSource( ... );
48 <jdeolive> SimpleFeatureType type = source.getSchema()
48 <jdeolive> now break
48 <jdeolive> unless they declare FeatureSource<SimpleFeatureType>
48 <jdeolive> am i correct?
49 <jdeolive> or unless they cast
49 <gabriel> hmmm no, you already got a simplefeature only capable datastore
49 <gabriel> so you should be good?
49 <jdeolive> but
49 <jgarnett> (sorry guys customer call, will be back)
50 <jdeolive> FeatureSource now looks like FeatureSource<T extends FeatureType>
50 <jdeolive> and declares T getSchema()
50 <aaime> yet with type narrowing on return values we can avoid that parametrization no?
51 <gabriel> no
51 <jdeolive> aaime: right but then that means we need a super class
51 <gabriel> cause we're looking for a single FeatureSource
51 <jdeolive> right
51 <gabriel> right
51 <aaime> ah sorry
52 <aaime> but if we introduce params we break client code no?
52 <gabriel> no, they just get warnings
52 <gabriel> about their variables not being parametrized
52 <gabriel> ?
52 <aaime> hum
53 <jdeolive> in some cases they can break, and i think this is one of them
53 <aaime> not so sure
53 <jdeolive> since FeatureSource is genericized to featureType
53 <jdeolive> and anything that extends it
53 <-- cholmes has left this server.
53 <jdeolive> so if a cdeclaration does not declare that it narrors the parameter ot SimpleFeatureTYpe
53 <aaime> but users expect SimpleFeatureType
53 <jdeolive> the compiler will assume the generic, which is just FeatureTYpe
53 <jdeolive> does that make sense?
53 <jdeolive> this is hard to do without code in front of me
54 <aaime> so for backwards compatibility we need the class hiearchy
54 <jdeolive> aaime: well that would fix it
54 <jdeolive> but i really dont like that
54 <gabriel> I'm still not sure
54 <aaime> breaking backwards compatibility would be worse?
54 <jdeolive> i would almost be willing to give up some of our backwards compatability to keep our api cleamn
54 <gabriel> existing client code got a datastore which narrows to Simple
55 <aaime> Gabriel, you mean
55 <aaime> FeatureSource<SimpleFEatureType> datastore.getFeatureSource(...)?
55 <aaime> but in lot of places feature source is used stand alone
55 <jdeolive> right
55 <aaime> received from somewhere else
55 <jdeolive> this will work ok
56 <aaime> and you don't have params around
56 <jdeolive> SFT t = dataStore.getFeatureSource(..).getFeatureTYpe()
56 <jdeolive> but this will fail
56 <jdeolive> FS s = dataStore.getFeatureSOurce(...); SFT t = s.getFeatureType()
56 <aaime> right
56 <jdeolive> ibut as andrea says... there is probably a lot of code which stores the FS in a variable
57 <gabriel> now I see
57 <jdeolive> there is one important thing to keep in mind here
57 <jdeolive> the way things are now
58 <jdeolive> there are already breakages with code that is trying to upgrade to 2.5
58 <jdeolive> the way we did the SimpleFeature change is not back compat
58 <aaime> ok, but we should try to keep the incompatible changes down to a minimum
58 <gabriel> so if we already broke, call it 3.0 and do things right
58 <jdeolive> aaime: agreed
59 <aaime> do things right == generify?
59 <jdeolive> gabriel: agreed...but that comes with more political consequences than just backward compat
59 <gabriel> have only one new class, a superinterface for DataStore
59 <jdeolive> and lets be honest guys
59 <gabriel> I understand, its just an impulse
59 <jdeolive> we have already pissed enough people off with api changing
00 <gabriel> true
00 <jdeolive> i mean... the only peopel that really use geotools are the people like us who work on it
00 <jdeolive> dont get me wrong
00 <jdeolive> i agree with you aaime
00 <jdeolive> but we should also be realistic about the situation
01 <aaime> jdeolive, I would not count on "only us are really using geotools"
01 <aaime> I know quite some users here in Italy that only use gt2
01 <gabriel> yet I see no way of being realistic and not introducing superclasses for datastore/source/store/locking
01 <aaime> and don't use udig or geoserver
01 <gabriel> which seems to be what you want
01 <jdeolive> ack... it seems we are at an impasse
02 <jdeolive> so for the people here
02 <aaime> just look at the amount of poeple hitting gt2-usrs
02 <jdeolive> lets do an informal vote
02 <gabriel> really, we can introduce the type hierarchy and go throuh a deprecation cycle?
02 <gabriel> I even would prefer not to deprecate
02 <gabriel> but keep it working
02 <jdeolive> would you rather a) introduce an extra layer of interfaces or b) break some api and parameterize our api
03 <aaime> I'd say, if we play it so that the changes are pretty mechanical, like the ones for SimpleFeature
03 <aaime> then ok
03 <aaime> otherwise better have the two layers
03 <gabriel> I need it working asap in udig, so I'm for a) or I would need to redo udig
03 <jdeolive> aaime: i think the changes would be mechanical
03 <jdeolive> i mean... all you ahve to do is s/FeatureSource/FeatureSource<SimpleFeatureTYpe>/g
03 <jdeolive> and everything works
04 <aaime> gabriel, for the simple feature change jgarnett and jesse worked... a couple of days?
04 <jgarnett> back; written up enough of the hybrid approach so you can see how it would work
04 <jgarnett> http://docs.codehaus.org/display/GEOTOOLS/Alternative+4+Hyrbrid
04 <gabriel> hrmmm
04 <jdeolive> gabriel: if you are talking about getting somet4hing for fgdc i think there is some leeway there
04 <aaime> jgarnett, how much did you take to migrate udig trunk to SimpleFeature & co?
05 <jgarnett> in a word ... @#$%
05 <jgarnett> actually it was not too bad; we just did not have enough people.
05 <jdeolive> jgarnett: we are talking just getting code to compile
05 <jgarnett> took about 3 days for the first cut
05 <jgarnett> and 15 days for it to work
05 <jgarnett> create feature type dialog still does not work.
05 <jdeolive> keep in mind udig jumped from 2.3 to 2.5 did it not?
05 <aaime> wow, a lot more... with Geoserver we were up in a few days?
05 <jgarnett> 2.2 to 2.5
05 <gabriel> from 2.2
05 <aaime> ah right
05 <jdeolive> aaime: right... because gs kept up with gt releases
05 <-- dany_r has left this server ("ChatZilla 0.9.79 Firefox 2.0.0.11/2007112718").
06 <jgarnett> udig hits things hard; and a lot of the geotools cade base had suffered bit rot.
06 <jgarnett> (ie shapefile editing)
06 <jdeolive> i do think the changes are completely mechanical
06 <jdeolive> that people weould have to make...
06 <jgarnett> so I am lost on this meeting; can anyone look at that Hybrid page and give me feedback?
06 <jgarnett> I had one technical question
06 <jdeolive> jgarnett: it is plan a)
07 <jdeolive> introducting an entire new layer of data access api
07 <jdeolive> which i dont like
07 <jdeolive> personally
07 <jgarnett> (you mean a super class?)
07 <gabriel> so, if we go for a single parametrized FeaureStore, how this apply to Feature: void modifyFeatures(AttributeDescriptor[] type, Object[] value, Filter filter)
07 <aaime> it would be exactly the same?
07 <jgarnett> wait hold on gabriel; want to make sure I understand ...
07 <jgarnett> do we have 1, or 2, or 3 datastore abstractions...
08 <jdeolive> 1
08 <jgarnett> 1. using generics all the time (gak!)
08 <jdeolive> for datastore
08 <jdeolive> and everything else is prameterized
08 <jgarnett> 2. an abstraact one, and then a specific subclass for SimpleFeature/SimpleFeatureType (minimum I would accept)
08 <jgarnett> 3. or three a common super class for both the SimpleFeature and the Feature case.
09 <jgarnett> nope 1 datastore and generics will not cut it, you can do two at a mimum.
09 <jgarnett> and limit generics to the Query object.
09 <gabriel> jdeolive wanted to mean your 2.
09 <gabriel> no?
09 <gabriel> no, sorry
09 <jdeolive> wait lets back up for a sec
09 <jdeolive> we have two alternatives right?
09 <jgarnett> let me hunt down the names we used in email; or I will go insane...
09 <jdeolive> jgarnett: we are summing up here for you
09 <jgarnett> we have 4 alternatives
09 <jdeolive> that will just confuse more
09 <aaime> jgarnett put on the table
10 <aaime> the fact we should parametrize Query too
10 <jdeolive> can we levae that out please
10 <aaime> to make it use Name instead of String
10 <jdeolive> or at least move it to a new agenda item
11 <jdeolive> agreed?
11 <gabriel> jgarnett: in your alternative 4 page, I can't use current DataStores as Data instances
11 <jgarnett> sorry; I went away to write up the hybrid approach in order to talk about it with everyone. I know that made me miss a lot of the conversation here but I though it was worth it.
12 <jdeolive> jgarnett: i am trying to sum it up for you!!
12 <jgarnett> okay ...
12 <jdeolive> so shall i continue?
12 <jdeolive> i want to make sure we are all on the same page here
12 <jgarnett> please; I am only listening to you for now
12 <jdeolive> gabriel + aaime?
12 <gabriel> go ahead please
12 * jdeolive wishes there was a puppet to pass around to know who the speaker was
13 <jgarnett> re /nick yourself as puppet
13 <jdeolive> haha
13 <jdeolive> anywho
13 <jdeolive> ok
13 <jdeolive> so we seem to have boilked it down to two approaches
13 <jdeolive> the first
13 <jdeolive> is a new layer layer of super interfaces for DataStore, FeatureSource, and everything else
13 <jdeolive> the reason being
14 <jdeolive> that we cannot be backwards compat about everything without them
14 <jdeolive> the second al;ternative
14 <jdeolive> is to just have a superinterface for DataStore
14 <jdeolive> with parameters for Feature and FeatureType
14 <jdeolive> the subclass (DataStore)
14 <jdeolive> narrows all teh parameters to SimpleFeatureType and SimpleFeature
14 <jdeolive> the problem with this
14 <jdeolive> is that this code will no longer compile
15 <jdeolive> FeatureSource s = datraStore.getSchem(...)
15 <jdeolive> SimpleFeatureType sft = s.getSchema()
15 <jdeolive> sorry, that should have been dataStore.getSource(..)
15 <jgarnett> yes, got it.
15 <jdeolive> but this is nice
15 <jdeolive> because we only have one FeatureSource class
15 <CIA-23> simboss 2.4.x_rs * r29131 geotools/modules/library/render/src/main/java/org/geotools/renderer/lite/gridcoverage2d/ (12 files in 2 dirs): -committing latest bunch of work on RasterSymbolizer
15 <jdeolive> but its not 100% backwards comat
15 <jdeolive> however
15 <jdeolive> the changes are purely machanical
16 <jdeolive> s/FeatureSource/FeatureSource<SimpleFeatureTYpe>/g
16 <jdeolive> done
16 <-- simboss has left this server ("ChatZilla 0.9.80 Firefox 2.0.0.11/2007112718").
16 <jdeolive> jgarnett: does that make sense?
17 <jdeolive> gabriel: did i sum it up propperly?
17 <gabriel> yes
17 <jgarnett> thinking
19 <gabriel> time to choose your poison
19 <jgarnett> okay I understand.
19 <jdeolive> cool... so an informal vote
19 <jdeolive> a or b
19 <aaime> the changes are a little more
19 <jgarnett> discussion
19 <aaime> you have to change FeatureStore and FeatureLocking as well
20 <jdeolive> aaime: elaborate
20 <jdeolive> right
20 <aaime> in all places where they are used as variables
20 <aaime> and as implements
20 <jdeolive> FeatureREader as well
20 <jgarnett> okay; can I run through something now justin.
20 <jdeolive> but all of them are simple a regex
20 <aaime> FeatureREader would need 2 params
20 <aaime> ugly
20 <jgarnett> I can respond to what you outlined first if you want.
20 <jdeolive> jgarnett: go ahead
20 --> cholmes has joined this channel (n=cholmes@cpe-66-108-80-238.nyc.res.rr.com).
21 <jgarnett> I will respond first; then I really want to go over the hybrid thing with you.
21 <jgarnett> (just focus on the Query when you read that page)
21 <jgarnett> response.
21 <jdeolive> i am not even thinkng about that yet
21 <jdeolive> completely seperate issue in my mind
21 <jdeolive> i cant do this meeting if we go on tangents
21 <jdeolive> its hard enough keeping things straight as it is
21 * jdeolive is done
21 <jgarnett> okay so we have a couple of things on the table that people want to think about; you are focused on the number of classes
21 <jgarnett> and I am focused on the number of generics
22 <jdeolive> it is more than the number of classes but continue
22 <jgarnett> I like you reducing the number of classes to 2
23 <jgarnett> It is going to be really tempting to make SimpleFeatureReader extends FeatureReader<SimpleFeature>; even though it does not add anything.
23 <jdeolive> i could go for that since as andrea says... it will need two parameters
23 <jdeolive> which is ugly
23 <jgarnett> is there anything else you wanted me to get out of your proposal?
24 <jdeolive> just one
24 <jgarnett> It is a nice breakdown; I like "two" classes rather than "three" (an abstract interface is not fun)
24 <aaime> jdeolive, try to make that a subclass and see if the single layer of interfaces still works
24 <jdeolive> that hte reason i am against it is that another layer of abstraction i think really makes things messy
24 <jdeolive> aaime: you dont think it will work?
24 <aaime> I'm not sure
24 <jdeolive> i guess it wont...
25 <jgarnett> what is? the abstract super class? yes I just used it for the hybrid page because that is what gabriel had.
25 <aaime> I think having one subclass will force you to make the others as well
25 <jdeolive> i have an idea for FeatureReader though
25 <aaime> jgarnett, having a reader subclass to avoid the two params that the generic version would need
26 <jdeolive> we could forget about paramaterizing FeeatureType...
26 <jdeolive> but again that would be a breakage... a mechnical one.. but
26 <gabriel> ok, now the conv seems to be going trhou decreasing the use of generics, before it was towards increasing it
26 <jgarnett> gabriel there are different motivations afoot.
27 <gabriel> still I agree with jdeolive on choosing between alternatives a or b
27 <jgarnett> so far I think going with a two class approach seems fine.
27 <jdeolive> yeah we should first determine if some mechanical breakage is acceptable to people
27 <jgarnett> justin I would prefer mechanical breakage over more moving parts.
27 <jdeolive> as would i
27 <jdeolive> so that is two votes for b
27 <jgarnett> let me know when we can talk about generics
28 <jdeolive> aaime and gabriel
28 <jgarnett> it is odd for me justin; I feel like I am voting on something that does not matter to me
28 <jgarnett> ie
28 <jdeolive> this is note a vote
28 <jdeolive> call it a "preerence" if it makes you feel better
28 <jgarnett> okay my preference is two fold:
28 <jdeolive> jgarnett: can you wait for gabriel and aaime
29 <aaime> jdeolive, I'm pretty much twisted
29 <jgarnett> - a single super class using the minimal amount of generics
29 <jgarnett> - use generics only for parameters like Query
29 <aaime> I don't want to see a one km long param list in the code
29 <jdeolive> aaime: nor do i
29 <jgarnett> aaime++; I don't think we need to. only forced into parameters for things like Query
29 <jgarnett> (codehaus is down)
30 <gabriel> I feel better with superinterfaces only for datastore/source/store/locking and being backwards compatible
30 <jdeolive> its hard to make that judgement until we actually look at some code though...
30 <aaime> but the generics proposal seems to to ask for a long param list?
30 <jgarnett> but the hybrid proposal does not
30 <jgarnett> generics proposal is over kill
30 <jdeolive> two params at hte most
30 <jgarnett> I only have one justin; what are the two for you?
30 <jdeolive> jgarnett: not sure what you mean
30 <aaime> All in all I prefer the class hierarchy
30 <jgarnett> yes; I don't think you know what I mean.
30 <aaime> it makes the simple case real simple
31 <gabriel> the hybrid proposal as it is does not buys me out of the box usage of current datastores as generic ones
31 <aaime> and the complex case equally simple for the client
31 <aaime> with minimum amount of extra work for implementors
31 <jdeolive> ok.. it seems we moved to 3 alternatives now...
31 <jgarnett> gabriel let me update the page; and remove the code examples
31 <jgarnett> I am doing a bad job of them and they are loosing the point.
31 <gabriel> take your time, np
31 <jdeolive> jody, that page with Query in it is useless to this discussion imho
32 <aaime> jgarnett, even to me, it seem Query could be discusse after we have chosen a path on the general architecture (or not?)
33 <aaime> yet, Query parametrization would bring the number of params to two for DataStore and co
33 <gabriel> it seems to me jody is using query as to reduce the ammount of parametrization
34 <jdeolive> i fail to see the point of parameterizing query...
34 <jgarnett> justin we are coming at this from different angles
34 <jgarnett> okay let me try again ...
34 <aaime> jgarnett has added a param over a non parametrized version so it's adding one, not removing
35 <jgarnett> - generics for Feature and FeatureType are not needed; that can be covered with type narrowing
35 <aaime> (as far as I can see)
35 <jgarnett> - we only need generics for the method parameters: Query
35 <jgarnett> that is the trade off I am trying to see discussed.
35 <jgarnett> I have updated the page to reflect a single super class now.
35 <jdeolive> you want to param Query for coverage stuff?
35 <jgarnett> (but codehaus is not happy_
35 <aaime> jgarnett, what is the query param used for, to start
36 <jgarnett> getFeature( Q query )
36 <-- cholmes has left this server (Read error: 104 (Connection reset by peer)).
36 <jgarnett> sorry getFeatures
36 <jgarnett> or getFeatureReader
36 <jgarnett> I don't really mind what is returned; because we can type narrow the return value
36 --> cholmes has joined this channel (n=cholmes@cpe-66-108-80-238.nyc.res.rr.com).
36 <gabriel> the problem is not getFeatures but, say, addFeatures(FeatureCollection) and the like as far as I can tell?
36 *** zzorn_away is now known as zzor.
36 *** zzor is now known as zzorn.
37 <jdeolive> ok... seems this conversation has gone a stray
37 <jdeolive> sigh...
37 <jdeolive> i thought we were making headway
37 <aaime> jgarnett
37 <jgarnett> justin this is the only conversation I have been trying to have.
37 <aaime> that is not telling me why you need params in Query
37 <jgarnett> do we have an agenda if so I can put it on the agenda.
37 <jdeolive> I ASKED YOU TO DO THTA BEFOER!!!!
37 *** jgarnett sets the channel topic to "1) main goals 2) super class 3) generics".
37 <jgarnett> done
38 <jgarnett> I assume we are on 2) and I should be quiet for a bit.
38 <jdeolive> we were trying to figure out what people valued more
38 <aaime> jdeolive, it seems to me Query parametrization is relevant to generics, because it could be implemented in your generic only approach
38 <aaime> but it would add a new type param
38 <jdeolive> backwar compat, or cleaner api
38 <jdeolive> cleaner being a relative term i admit
39 <aaime> too many params == not clean (imho)
39 <jdeolive> i know that
39 <jdeolive> sorry
39 <jdeolive> can you make me understand why we need to parameterize query?
39 <jgarnett> justin I would prefer a clearer api; a mecanical upgrade process (as clients move to Java 5) is an acceptable thing.
39 <jdeolive> i mean... why do we want a subclass superclass of it?
39 <jgarnett> indeed clients would prefer we use Java 5 to clean up the API.
39 <aaime> jgarnett, you're dodging the question
39 <jgarnett> that is my preference. is that what you wanted to know?
40 <jdeolive> jgarnett: yes, thank you
40 <aaime> what are the params in Query for
40 <jgarnett> andrea; I am in trouble for talking about Query; I am going to try and stick to the agenda.
40 <jdeolive> well no, i need to understand this
40 <jdeolive> because there is something fundamental that i am missing
40 <aaime> please Jody
40 <jgarnett> okay
41 <jgarnett> full on generics is a bit of a pain; so I would like to reduce our use to only the places that we are forced it.
41 <jgarnett> the only place I am forced to is on method parameters
41 * jdeolive starts to beat his head against his desk
41 <aaime> right, still does not tell me why do you need to subclass Query?
42 <jgarnett> I need to super class Query
42 <aaime> whatever, why??
42 <jgarnett> so we can gave List<Name> getNames()
42 <jgarnett> because String[] does not cut it for the Feature case.
42 <jdeolive> dude
42 <jgarnett> String[] only works for SimpleFeature right?
42 <jdeolive> deprecate the method that returns straings and add a new one
42 <jdeolive> which returns Name
43 <jdeolive> jgarnett: no
43 <jdeolive> SimnpleFeature works with Name as well
43 <jgarnett> yes I know that justin
43 <jgarnett> but as a way for users to say what they want
43 <jgarnett> providing us with a String[] is only good when working against SimpleFeature
43 <jgarnett> (other than that we need more from them: List<Name> )
43 <jdeolive> yes i realize that
43 <jgarnett> okay.
44 *** You are now known as groldan.
44 <aaime> a convinience constructor that accepts String[] and turn it into
44 <jdeolive> so why do we need a subclass to do that?
44 <aaime> List<Name> would do the trick for the users no
44 <groldan> even more
44 <jgarnett> we don't we need a super class; when working against Feature
44 <groldan> we'll need Query.getNamespaceContext() or such
45 <jdeolive> sure, lets make the mods to Query we need to
45 <jdeolive> not subclass it and parameterize it in the rest of the api
45 <jgarnett> basically I need a palce for gabriel to define what it means to query Feature content (rather than SimpleFeature)
45 <aaime> and keep it one interface
45 <jdeolive> that seems crazy to me
45 <jgarnett> so it sounds like you would like us to mod Query ?
45 <jdeolive> please!!!!
45 <jgarnett> okay
45 <jdeolive> why would you not do that?
45 <aaime> lol
45 <jdeolive> and better question
45 <jgarnett> so justin before you go insane.
45 <jdeolive> why would you think i did not want you do thaty?
46 <jgarnett> because we like to do this generic case, and then add more stuff for the simple case.
46 <aaime> is that really necessary
46 * jdeolive thinks he is speaking in klingon
46 <jdeolive> anyways
46 <aaime> ka-pla!
46 <jgarnett> okay
46 <jgarnett> stop
47 <jgarnett> you are getting distracted by Query
47 <jgarnett> and missing the point
47 <jdeolive> we agree ont hat
47 <jgarnett> that we can limit generics to method parameters only.
47 <jgarnett> that was the only point I was trying to make.
47 <groldan> jody's approach begs for "cleaner api", jdeolives for "pragmatic one"
47 <groldan> where cleaner keeps being a relative term
47 <aaime> the point is that in a pure subclassing approach we don't need generics at all afaik
48 <jgarnett> we still need them; but only when we got parameters.
48 <aaime> grrr
48 <jdeolive> right... but that is for simple feature vs feature... why does query even enter into it
48 <jgarnett> gabriel point out that addFeatures( ... ) would need one.
48 <groldan> jgarnett: limiting generics to method parameters only lead me to the ugly stuff on the page
48 <jdeolive> ok
48 <aaime> but we are saying there is no need for that
48 <jgarnett> query was just an example.
48 <jgarnett> you killed it as an example.
48 <groldan> like the parameters that need to be parametrized are FeatureCollection and FeatureReader
48 <jdeolive> ok, can we stop talking about it then?
48 <groldan> more then query
48 <aaime> jgarnett, we don't need out of the blue examples
48 <aaime> we need a solid proposal on the datastore issue
48 <jdeolive> aaime: well put
49 <jdeolive> ok, we are going in circles
49 <aaime> and as I see it, we don't need params at all in the
49 <jgarnett> well I asked for this to be written up and it wasn't so I am scrambling here andrea.
49 <aaime> we dont' need params at all in the case where we do two layer approach
49 <groldan> yeah, hadn't real time to do so jody, my bad
49 <jgarnett> I am trying to offer an alternative to generics.
49 <aaime> since all the type narrowing we need is on return types
49 <jgarnett> aaime++
50 <jgarnett> (thank you that is all that I was trying to communicate)
50 <jdeolive> wow, you could have done that way easier
50 <jdeolive> moving on
50 <jgarnett> well it was not working for me
50 <jdeolive> so i think we need to code up some examples
50 <jdeolive> i volunteer to code up the generic case
50 <jdeolive> keep in mind
50 <jgarnett> can we make a spike directory?
51 <jdeolive> sure
51 <jgarnett> yeah this conversation would of gone better in code 
51 <aaime> can we do the same examples in both cases
51 <jdeolive> aaime: great idea
51 <aaime> so that it's easy to see the differences
51 <aaime> and each camp will try to make up examples
51 <jdeolive> works for me
51 <jdeolive> idea
51 <aaime> that show the shortcomings of the other
51 <jgarnett> andrea can we do the minimal generic case together?
51 <jdeolive> can we just spike the api module and do the work?
51 <aaime> in the end we should end up with a nice comparison
51 <jgarnett> I got lots of work to do...
52 <jdeolive> jgarnett: that is fine, can handle this one
52 <jgarnett> and I don't want to put ideas into danger just because I have no time.
52 <jdeolive> with some help from gabriel coming up with the superclass case
52 <jgarnett> both of them?
52 <aaime> jdeolive does generics
52 <jgarnett> okay...
52 <groldan> since I already have some code
52 <aaime> gabrie does subclass?
52 <groldan> why don't I move it to spike
52 <jgarnett> good thinking
52 <groldan> I do subclass
53 <aaime> jdeolive, groldan
53 <jdeolive> agreed
53 <aaime> it would be nice to have a page listing code exemplars
53 <aaime> both cases side by side
53 <jdeolive> aaime: i will do better and actly write code that compiles against api
53 <groldan> I had sample implementations of them, that may count as code examples, or implementation examples
53 <groldan> had = have
54 <aaime> Well, in that case, two java files side by side doing the same things with both approaches?
54 <-- cholmes has left this server (Read error: 104 (Connection reset by peer)).
54 <jdeolive> aaime: sure
54 <jgarnett> so the next IRC breakout will really be a bake off.
55 <groldan> sooo, I do DataStore/source/store/locking superclasses with FeatureType/Feature parametrization on the general case and no parametrization on the simplefeature case
55 --> cholmes has joined this channel (n=cholmes@cpe-66-108-80-238.nyc.res.rr.com).
55 <aaime> groldan, you don't need to parametrize at all
55 <aaime> afaik
55 <aaime> all your params are hitting return values
55 <aaime> you can just type narrow them
56 <-- cholmes has left this server (Read error: 104 (Connection reset by peer)).
56 <groldan> that was the original idea!
56 --> cholmes has joined this channel (n=cholmes@cpe-66-108-80-238.nyc.res.rr.com).
56 <groldan> then it came out we needed to parametrize some arguments
56 <jdeolive> i think we are getting confused
56 <groldan> like for modifyFeatures(FeatureCollection)
56 <aaime> groldan, keep it simple
56 <jdeolive> there are actually 4 things here
56 <jdeolive> pure subclass
56 <jgarnett> you can always have the subclass accept more parameters
56 <jdeolive> subclass all interfaces with some paraming
57 <jdeolive> paraming with one subclass
57 <jdeolive> and all paraming
57 <jdeolive> actually... all paraming wont work
57 <jdeolive> so i guess there are 3
57 --> pramsey_ has joined this channel (n=pramsey@mail.refractions.net).
57 <aaime> groldan, so the need for params comes from FeatureStore?
58 <groldan> hmm yes
58 <groldan> afaik
58 <aaime> then can we just param that one?
58 <aaime> and leave the rest param free?
58 <groldan> hmmmm not sure
58 <groldan> guess not
59 <aaime> why not?
59 <-- pramsey has left this server (Read error: 113 (No route to host)).
59 <CIA-23> jdeolive * r29132 geotools/spike/jdeolive/api/: creating api spike
59 <groldan> at least not with a single getFeatureSource() method
59 <aaime> hum... well, we could overload instead of param in the subclass no?
59 <groldan> overload was the first approach, yes
00 <aaime> why was it rejected?
00 <CIA-23> jdeolive * r29133 geotools/spike/jdeolive/ (3 files): removing unused spike classes
00 <aaime> we have custom methods in SimpleFeature as well
00 <groldan> guess it was jdeolive?
00 <groldan> not really sure though
00 <aaime> I guess he was misunderstood
00 <aaime> in his attempt to present a single layer approach
01 <aaime> with params everywhere
01 <jdeolive> sorry, i am lost here
01 <-- cholmes has left this server (Read error: 104 (Connection reset by peer)).
01 <groldan> there's a way to have superclasses with no parametrization
02 <jgarnett> not sure; the compiler will know
02 <groldan> that means FeatureStore ends up with overloaded methods for addFeatures and modifyFeatures
02 --> cholmes has joined this channel (n=cholmes@cpe-66-108-80-238.nyc.res.rr.com).
02 <aaime> we have two ways to get attribute value in SimpleFeature
02 <jdeolive> akk... that seems ugly to me
02 <groldan> but that also meanse superclass for FeatureReader
03 <groldan> and FeatureCollection
03 <jdeolive> also somethign to keep in mind
03 <aaime> not more, not less than all the extra methods
03 <aaime> that are in simpleFeature?
03 <jdeolive> is that we are stuck with this api forever... backwards compat is only for one release
03 <aaime> same goes for SimpleFeature
03 <aaime> (or not?)
03 <groldan> no
04 <groldan> let people that don't care about complex feature keep things working
04 <aaime> see here: http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/feature/simple/SimpleFeature.html
04 <aaime> how many ways we have to get an attribute value in simple feature?
04 <groldan> as junit did for your tests
05 <aaime> lots because we have various getAttribute but also getProperty (coming from Feature)
06 <jgarnett> um question: what is going on? I thought this meeting was done ... are you guys designing the low-generic alternative now?
06 <groldan> we're running in circles
06 <aaime> we just kept on talking about the low generic alternative, yes
07 <groldan> once upon a time there were two alternatives that ensured the goals on my page were met, and the tradeoff was to choose over more generics or more superclasses
07 <groldan> more generics sort of dropped by its own weight as client code breaks
08 <groldan> but then a simple regex replace seemed fine
08 <groldan> and we were to choose one
08 <groldan> now we're getting again to a point where we focus on single spots loosing the big picture
08 <groldan> imho
08 <aaime> a proposal is made of big picture and details
09 <aaime> but the proposal having a big picture ok and details broken is useless imho
09 <aaime> (that is useful for discussion, not for implementation)
09 <jgarnett> okay so we are trying to move this discussion into code
09 <jgarnett> can we do that; and just keep with IRC / Skype windows going.
10 <aaime> well, I'm personally out of time
10 <aaime> dinner and then tennis
11 <aaime> (and then sleep, but I can pop in again for half an hour )
11 <groldan> no, give us time to digest it
11 <groldan> and arrange for tomorrow
11 <groldan> so eouropeans do not need to stay up till 5 am again
11 <groldan>
11 <aaime> ha ha
11 <aaime> I won't for sure
12 <aaime> I worked up to 1am yesterday
12 <jgarnett> thanks guys.
12 <aaime> and I've been sleepy all the day
12 <aaime> I need to sleep a lot
12 <jgarnett> worked? I though you were just hating referencing code?
12 <aaime> like a small child
12 <groldan> lol
12 <jgarnett> (some kind of Itallian excuse for fun)
12 <aaime> hammering it
12 <aaime> I actually fixed it in fact
12 <groldan> so I can compromise to code a spike and put it on svn
12 <jgarnett> yes; aaime++ thanks!
13 <aaime> groldan, sure
13 <groldan> just tell me which one
13 <groldan> or since its my proposal I can do both
13 <aaime> the full generics one is being done by Justin
13 <aaime> you do the others
13 <groldan> k
13 <groldan> full generics with simple superclass for datastore
14 <groldan> justin knows how to choose early
14 <aaime> do what you feel it's good
14 <jdeolive> groldan:
14 <aaime> there no point in coding something you hate
14 <aaime> can a painter paint a subject he does not like?
14 <groldan> so I'll take the fully backwards compatible now
14 <aaime> exactly
14 <groldan> and call it a tennis match (ie. made between gentleman)
15 <aaime> why not
15 <aaime> some sane competition does not hurt
15 <groldan> or I'll need to choose my side of the playing field again
15 <groldan> 
15 <groldan> thanks guys, it was an amazing meeting
15 <groldan> two hours long
16 <groldan> same bat-hour same bat-channel?
17 <groldan> aaime, jdeolive, jgarnett?
17 <jdeolive> hi
17 <groldan> I know I'm bad at jokes, yet please confirm
17 <jdeolive> sounds good to me
17 <groldan> cool
17 <jgarnett> hi
18 <jgarnett> gah!
18 <jgarnett> same time tomorrow? okay ...
18 <groldan> cool, with code at hand
Labels