A lazy meeting for a lazy community.
1) Meeting starts 20 minutes late because everyone waits for someone else to run things.
2) Most of the PMC doesn't show up enough to even say hello, almost no one participates.
3) No one so much as offers to post logs.
These are low days indeed in the community at large.
0) Whats up 1) Style proposal 2) Metadata renaming (proposal)
– Now talking on #geotools
– Topic for #geotools is: http://geotools.org
– Topic for #geotools set by jgarnett at Tue Jun 17 19:32:23 2008
<desruisseaux> Meeting time?
– desruisseaux has changed the topic to: 0) Whats up
<acuster> jgarnett, around!?
– aaime will be late tonight, I still haven't had dinner
<acuster> Eclesia hbullen jalmeida mauricio mgrant pramsey springmeyer wanna have a meeting?
– sfarber (email@example.com) has joined #geotools
<desruisseaux> Does anyone have agenda topic?
<Eclesia> styles once again
<Eclesia> and call for a vote on the proposal
– Eclesia remind the proposal page : http://docs.codehaus.org/display/GEOTOOLS/Upgrading+styles
<hbullen> sure one min
– vheurteaux (firstname.lastname@example.org) has joined #geotools
– desruisseaux has changed the topic to: 0) Whats up 1) Metadata renaming (proposal)
– desruisseaux has changed the topic to: 0) Whats up 1) Style proposal 2) Metadata renaming (proposal)
– afabiani (email@example.com) has joined #geotools
<CIA-26> desruisseaux * r30792 /trunk/modules/library/metadata/src/ (36 files in 6 dirs): Synchronized the collections used in metadata. Javadoc cleanup.
<acuster> Eclesia, why don't you start the meeting since you have things to discuss?
<vheurteaux> go Eclesia go !!!
<Eclesia> It's useless if nobidyes here
<acuster> Everyone is expected to read the weekly irc minutes, and PMC members are required to
<acuster> hence you discuss, even if no one is around
<acuster> and then they have something to read
<Eclesia> ok so : please vote for the style proposal. seens no one raised objections
<Eclesia> proposal page : http://docs.codehaus.org/display/GEOTOOLS/Upgrading+styles
<Eclesia> subject : upgrading the style package on new geoapi interfaces
<Eclesia> and fallow OGC Symbologie Encoding Specification, ISO 19117 portrayal and a part of OGC SLD 1.1
<Eclesia> if you have questions ...
<desruisseaux> Minor details
<desruisseaux> String getUnitOfMeasure();
<desruisseaux> Could it returns Unit instead of String?
<desruisseaux> We may need to define a Pixel constant...
<desruisseaux> (a Pixel Unit constant)
– johnValtus (firstname.lastname@example.org) has joined #geotools
– simboss (email@example.com) has joined #geotools
<Eclesia> If we can define a pixel unit then yes we can replace the string by a Unit
– ggesquiere (firstname.lastname@example.org) has joined #geotools
<Eclesia> or perhaps using "null" for the pixel unit
<Eclesia> seens is has no relation to any other units
<desruisseaux> Better defining a Pixel units
<Eclesia> it has*
<desruisseaux> "null" is rather used for no-units (which is not the same than pixel units)
– sfarber (email@example.com) has left #geotools
<desruisseaux> We can define a Unit without relation with other units.
<desruisseaux> (actually it has a relation, but admitely a complex one, so we may want to treat it as if it has no relation)
<Eclesia> noticed I didn't used "pixel" but display unit
<desruisseaux> Thats fine.
<desruisseaux> Other minor proposal:
<desruisseaux> Collection<String> getSemanticTypeIdentifiers();
<desruisseaux> Should we replace the String by an Enum?
<desruisseaux> Given that the allowed values is restricted.
<desruisseaux> (or maybe a CodeList if we want to allow peoples to expand the list)
<Eclesia> the specification says it's still in experimentation
<Eclesia> we should not limit possibility until we have more details
<Eclesia> (that's what I believe)
<desruisseaux> Then a CodeList may fit.
<hbullen> I agree with you eclesia
<desruisseaux> (CodeList can be expanded with user-provided elements)
– Eclesia have no objections
<hbullen> sounds good to me
<desruisseaux> I do not known well the style and symbolizer specification, but the proposal seems quite reasonable to me. Does anyone else have remarks?
<Eclesia> next topic ?
– acuster can see he's going to have to become a PMC member to slap some order into these IRC meetings.
<desruisseaux> Okay, I added my vote to the proposal.
<desruisseaux> Next topic
<desruisseaux> Metadata renaming
<desruisseaux> (Implementation class of course, not interfaces)
<desruisseaux> Proposal: http://docs.codehaus.org/display/GEOTOOLS/Naming+policy+for+GeoAPI+implementation+classes
<desruisseaux> 1) Brings cross-module consistency (metadata vs referencing vs coverage)
<desruisseaux> 2) Make apparent which classes are "abstract" in ISO sense (which is not necessary in java sense)
<desruisseaux> 3) Make apparent which classes are GeoAPI implementations (in theory to be hidden and created through a factory) and which classes are GeoTools specific.
<desruisseaux> Renaming would be performed through the usual "deprecated, delete at next release" cycle.
<desruisseaux> Comments, suggestions, objections?
– Eclesia community support +1 , I use those namings too
<acuster> are you proposing that all of geotools follow this?
<desruisseaux> I would propose that but would not take action outside the modules that I maintain - I would left the decision to maintainers.
<desruisseaux> Thanks Eclesia for your support
<acuster> for you the first glance of naming is looking for a different thing than for users
<acuster> I generally want to see which classes 'go with' which
<acuster> then I can sort out the five or ten together
<acuster> by looking at each in turn in the javadoc
<acuster> so I don't like DefautFoo
<acuster> being miles from AbstractFoo
<acuster> and in turn those being far from FooOne, FooTwo
<acuster> english is a shitty language for this since it puts the adjectives before the nouns
<acuster> So far I'm working with FooAbstract, FooDefault, FooSpecifc
<acuster> but I don't have your experience or needs
<acuster> so it's hard to know who we are targeting with our naming
– hudson (n=PircBot@188.8.131.52.static.nyinternet.net) has joined #geotools
<desruisseaux> Well, if we look at usage in JDK, I see both AbstractFoo and FooImpl, but I never saw FooAbstract... Between DefaultFoo and FooImpl, the former (DefaultFoo) seems to be used slightly more often, but not by far...
<desruisseaux> I often tend to take the Java Collection framework as a model, because it is often praised as one the the good part of Java library (the collection framework has win awards)
<desruisseaux> And they use AbstractFoo.
<acuster> you used to argue that all this would be taken care of by better and better javadoc tools...
<acuster> anyhow, you do as you see best and more power to ya
<desruisseaux> Yes this is also too. But when I develop GeoTools, I find more useful to separated GeoAPI implementation from support class than having everything in alphabetical order. So actually I find the English order (Abstract / Default in front) quite convenient after all.
<desruisseaux> (typo: this is also true)
<desruisseaux> And separating Abstract from Default is quite convenient too, since we typically want to instantiate only the DefaultFoo classes.
<desruisseaux> (so DefaultFoo are were I tend to look first).
<desruisseaux> typo: where
<desruisseaux> Okay, I guess that we will let the proposal sleep a few days and see later this week (I would like to know Jody's opinion).
<desruisseaux> I'm done.
<jgarnett> hi guys; I am teaching a class but I can try and answer a few questions.
– drywall406 (firstname.lastname@example.org) has joined #geotools
<jgarnett> I don't mind between Default and Impl; I just like things to be consistent. I am used to the XXXImpl from Eclipse land
<simboss> ciao jody+
<jgarnett> Also if there was anything I needed to vote on let me know
<desruisseaux> Hi Jody
<desruisseaux> There is Eclisia style proposal waiting for vote
<desruisseaux> I proposed few minor modification (getSemanticTypeIdentifiers() to returns CodeLists, getUnitOfMeasure to returns Unit), but this is not major.
<jgarnett> I was happy with your take on it martin; getRules() for thread safe access; and rules() direct live access (ie mutable)
<jgarnett> so it was up to Eclesia to say what he was building ....
<jgarnett> is it mutable?
<Eclesia> implementer choice
<Eclesia> I guess they will be mutable in gt
<jgarnett> well we need to know in order to define the interface
<jgarnett> if it is mutable we need a different API (ie with listeners)
<jgarnett> or at least some indication on what is allowed in the javadocs ...
<jgarnett> I think acuster went through my wiki ideas on the topic; style tends to be in the "prep the data (ie mutable)"
<jgarnett> and the pass it over for rendering (which assumes immutable)
<jgarnett> gotta go ...
<Eclesia> having a method rules or getRules is a different problem from mutable or immutable
<jgarnett> not according to martin; who wanted rules() naming to mean mutable ...
<jgarnett> (if I read his email right?)
<Eclesia> I think you misunderstood
<desruisseaux> No I don't means that "rules()" must be mutable
<desruisseaux> I realize that my email was giving this feeling.
hudson/#geotools geotools-trunk build fixed (http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/748/)
<desruisseaux> My idea was rather to let mutability decision to implementors
<desruisseaux> But if "rules()" is mutable, then it must be a living collection.
<desruisseaux> Again I'm using Java Collection framework as a model.
<jgarnett> from email:
<desruisseaux> Map.entrySet() or List.sublist doesn't need to be mutable
<jgarnett> Immutable collections: List<Foo> getRules()
<jgarnett> Live collections: List<Foo> rules();
<desruisseaux> Yes, I known that I said that.
<desruisseaux> "rules()" is a live collection: change to the underlying object are reflected in the collection view, and vis-versa.
<desruisseaux> But whatever those changes are allowed or not is implementor decision.
<desruisseaux> Again, what I'm proposing is exactly the same than Map.entrySet(), List.sublist, etc.
<desruisseaux> If Map is immutable, than Map.entrySet() is immutable as well.
<desruisseaux> If Map is mutable, then changes in this map are reflected in Map.entrySet() and vis-versa.
<desruisseaux> The spec doesn't said that Map.entrySet() has to be mutable or not.
<desruisseaux> It just said that is must reflect the content of the underlying Map in all time, even if one of those change.
<desruisseaux> This is different from getRules() / setRules(), since typical getter and setter involve cloning the argument.
<desruisseaux> I have to go. Bye all...
– desruisseaux has quit ("ChatZilla 0.9.83 Firefox 184.108.40.206/2008042015")
<Eclesia> I guess the meeting is finished
<Eclesia> please take time to vote for both proposals
<hbullen> before everyone gose could some one take a look at the mysql patches I have submited?
<Eclesia> you know who is the maintenar of the module ?
<jgarnett> okay makes sense
<hbullen> not really?
<jgarnett> I am not sure there is one
– johnValtus (email@example.com) has left #geotools
<jgarnett> aaime reviewed last time I think
<hbullen> It says he is the lead on codehaus
<hbullen> So I guess I'll bug him then