jgarnett: meeting time?
gdavis: yes
jgarnett: (if I can ask someone else to run the meeting; I am too stupid / slow today)
jgarnett: ...
jgarnett: agenda items
Eclesia: process proposal
jgarnett has changed the topic to: 0) what is up 1) SoC 2) Process
jgarnett: please change the topic to add an agenda item...
desruisseaux has changed the topic to: 0) what is up 1) SoC 2) Process 3) Maven 2.0.9
jgarnett: Martin are you content to talk about Range via email? Or do we need to say anything .. I would like to write up a page for the user guide when we have it sorted out.
desruisseaux: Jody, sire
desruisseaux: (sure)
jgarnett: okay, I was expecting andrea to talk about his many proposals last week. At the very least they have all been voted on by now ...
jgarnett: lets go
jgarnett: 0) what is up
desruisseaux: I'm still working on NumberRange, trying to get it working with generic. But it would be more "weak" generic than what we previously has (a little bit like java.util.Collection which have a contains(Object) method, not contains(E))
jgarnett: jgarnett - installing arcsde and oracle and battling version hell between them
gdavis: gdavis: finishing up the process module and starting the gt-wps module, which is much like the wms module but for wps requests
jgarnett: (aside: martin I know how you can do that one better; but you may need to sacraface some of your constructors to get there...) Subject for after meeting ..
desruisseaux: (Jody: no need to sacrifice constructors - the problem is not there).
desruisseaux: (I means, I deprecate constructors, but they can be removed in next releases rather than now)
jgarnett: aaime did you have anything for the agenda? we are already moving ....
desruisseaux: No, new NumberRange<Integer>( 1, 1 ) can work.
jgarnett: 1) SoC
ggesquiere [n=gilles@ALyon-152-1-142-149.w86-209.abo.wanadoo.fr] è entrato nella stanza.
jgarnett: Deadline is passed; we will get students some time this week (I think...)?
jgarnett: So we will need all hands on deck answering the user list etc....
jgarnett: that is about all - thanks to Mentor's for volunteering; and to the many applicants - a lot of interesting ideas all around.
jgarnett: anyone else ...
jgarnett: 2) Process
jgarnett: gdavis ...
gdavis: ok regarding process module, we need to sort out the following concerns: process as beans, runnable, using ISO 19111 parameter as a base for ours, removing the hint attributes from the parameter class.
jgarnett: I think I can do this quickly:
jgarnett: - process parameters as beans; good idea - we tried it and it does not work a) internationalization support is terrible b) metadata such as FeatureType or CRS cannot be communicated
aaime: hum....
jgarnett: - Runnable can be considered; but it goes against the idea of a ProcessListener
jgarnett: - using ISO 19111 parameter was terrible the one time we tried it for a dynamic service; I never want to see that again.
aaime: can you elaborate at bit on each one?
Eclesia: I dont understand your agument against runnable
jgarnett: I think a lot of this discussion has been going on via IRC; we need to send emails to the list now and again...
desruisseaux: Jody, I never understood what didn't worked for you regarding ISO 19111 parameter. Could you post on email (or on a wiki page) an example please?
jgarnett: - http://docs.codehaus.org/display/GEOTDOC/ProgressListener
desruisseaux: I don't understand neither the argument against Runnable.
jgarnett: shows how to use a progress listener
sfarber: simboss, you want to prod more PMC into voting on the RS prop?
jgarnett: the trick here is that the listener is provied by the code that actually runs the thing
jgarnett: if we seperate that ( with a setProgressListener) we needless open up the door to mistakes and deadlock.
sfarber: (oops, thought we were in agenda-gathering phase. I'll shut up now)
jgarnett: Eclesia; it is a coding style choice - not a technical limitation.
desruisseaux: Jody, why? It is common to have "addFooListener" methods in worker classes (e.g. ImageReader.addImageProgressListener(...))
desruisseaux: After all, more than one listeners may be interrested to known about the progress...
jgarnett: martin; about ISO19111 parameters; I spent two months with you sorting it out; and we made a WMS GridCoverageExchange that used it. But the result was so crazy that we could not build a user interface based on the provided ParameterGroupDescriptor and ParameterGroup objects.
aaime: desriusseaux, yes, it's the swing style, and it needs special handilng to avoid memory leaks
aaime: (example: http://www.javalobby.org/java/forums/t19468.html)
jgarnett: martin you are correct; that is common; the style of programming I showed for ProgressListener is as much a bout "flow control" and the ability to interrupt as it is about reporting progress.
desruisseaux: So why not a Process.addProgressListener(...) method? (using WeakReference or not at Process implementor choice)?
jgarnett: Basically I want the code that "starts" the Thread to also provide the ProgressListener. Giving the responsibility to anyone else is a mistake ...
jgarnett: the easiest API way to enforce this is by using a process( ProgressListener control); method
jgarnett: so yes martin; the approach you describe works; using ProgressListener as a parameter works as well - and forces the programmer starting the Thread to take responsibility (ie the goal here is to assign responsibility to the correct programmer)
desruisseaux: Jody, I disagree. A Swing widget may be interrested to known about the progress but may not want to start it itself. The progress would be rendered in some widget in Swing threads. The process could be started by any other threads.
desruisseaux: Jody, there is my use case:
jgarnett: I understand; however I don't agree - it is the interupt case that gets me.
acuster [n=acuster@rab34-2-82-230-29-3.fbx.proxad.net] è entrato nella stanza.
jgarnett: please continue martin ...
desruisseaux: 1) A process is to be run in some background thread.
desruisseaux: 2) We want to monitor progress in a Swing widget.
pramsey ha abbandonato la stanza (quit: ).
desruisseaux: 3) We want to give the process to a java.util.concurrent.Executor, which will start the process in some threads that it control itself
desruisseaux: (i.e. using a ThreadPool)
desruisseaux: So we create the Process
desruisseaux: Swing register itself as a listener
jgarnett: okay so I understand your use case; and being a control freak of an API designer I want to ensure that the code that is handling all the threads is forced to know what is going on with respect to monitoring and canceling the thread.
desruisseaux: We submit the Process to the Executor, which will start it later as it see fit.
jgarnett: So if you had a "ProcessManager" model; the ProcessManagerView may very well use a swing based progress listener to do the work; but I want to force the programmer to keep there head up and make that judgement call.
aaime: desruisseax, you could get what you want by creating a wrapper around the process that turns it into a Runnable
aaime: jgarnett, having a single listener seems limiting thought
jgarnett: I had not thought explicitly about java.util.concurrent.Executor; I would be surprised if they did not have some of these facilities already.
jgarnett: aaime you are correct; the limitation is on purpose.
aaime: why?
desruisseaux: My goal is to get a Process framework fitting nicely in java.util.concurrency
jgarnett: (note all of this is a set of tradeoffs; I don't mind negotiating on this ... )
jgarnett: I am drawing a hard line here to make sure I am understood.
jgarnett: martin that was not listed as one of the goals for this work; it may be a useful goal - do you have some time to devote towards it?
aaime: I do understand the memory leak issue, I've been caught more than once in it with non trivial listener setups
desruisseaux: I can work with Eclesia
jgarnett: one of my goals is to intergrate with workflow engines and eclipse jobs for example ...
aaime: but I don't understand the single listener limit
desruisseaux: Memory leek seems a separated issue to me.
aaime: desriusseaux, given how common they are with swing, I'd say it's a design mistake
aaime: (see also http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4147808)
***Eclesia agree with aaime
Eclesia: a normal listener system would be better than a monitor
jgarnett: aaime; the single listener limit is just a choice; between limiting code to a single listener (you can always write a ProgressDispatchListener) and avoiding setProgressListener ....
jgarnett: so let me ask Eclesia; you understand the ProgressListener approach now? And you would simply like to use more than one ProgressListener?
aaime: jgarnett, that limitation could of course be removed using a dispatcher but it's annoying... why can't you accept a "Listerer..." param
jgarnett: I also should ask if what I am trying to do here is too subtle? is my point not comming across.
desruisseaux: A paranoiac code would need to invokes getProgressListener before setProgressListener, and creates come CompoundProgressListener if the former returned a non-null value. A addProgressListener(...) method is simplier.
Eclesia: yes, i would like more, I was kind of "foreced" to used monitor
Eclesia: forced*
jgarnett: yes; that was my goal
jgarnett: to force you to use monitor; and thus respect the workflow engine or user.
jgarnett: the other aspect to this is that what we have here is not a normal listener; the idea is to decompose the listener with sublisteners as code is delegates to other code.
desruisseaux: Jody what you call Monitor looks like this interface, or do I'm wrong?
desruisseaux: http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html
Eclesia: handling a listener list is not a hard thing...
jgarnett: yes
desruisseaux: Basically I strongly feel that one of the top priority of a process framework would be to fit nicely in the java.util.concurrent package.
jgarnett: and it was not the point.
jgarnett: new Runnable()

jgarnett: moving on one of my priorities is to make sure that I can fit into a workflow engine with some form of job control.
jgarnett: as such I need some kind of callback object.
jgarnett: Is the fact that this is called "Listener" the source of confusion?
desruisseaux: Jody, a wrapper add conceptual weight... More concept to handle for the developper rather than the one he is used to == more complexity...
jgarnett: you are correct
jgarnett: however a wrapper is almost always required
desruisseaux: Why?
jgarnett: see SwingWorker for just such a wrapper
jgarnett: Runnable is also a wrapper; you are not often making those directly ...
jgarnett: because code requires parameters; flow control; and output
desruisseaux: If it is in order to get the result of some computation, java.util.concurrent.Callable do just that.
jgarnett: Runnable usually depends on object fields; or final parameters for the input; and sideeffects for the output.
desruisseaux: Java.util.concurrent gives you everything needed for getting an output object.
desruisseaux: Callable is like Runnable but returns a value.
jgarnett: martin we are missing something
jgarnett: how do I stop a runnable
desruisseaux: Future.get() can be invoked in any thread, wait for Callable to finish his works and returns that value.
jgarnett: that is all I want to know.
desruisseaux: Jody, you stop a runnable with Future.cancel() !!
desruisseaux: http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html#cancel(boolean)
jgarnett: Note Callable.call() is another example of a wrapper that is similar to Runnable; ie similar problem.
jgarnett: good now we are making progress
desruisseaux: Callable doesn't need to be a wrapper. Any developper can implements it directly if he wish
gdavis: if it has a cancel feature, im fine with using runnable
jgarnett: it does
jgarnett: martin can we make something that reports Progress using an extention of Future? or is that already done somewhere ...
desruisseaux: We could extends Future
desruisseaux: I have no objection to that.
jgarnett: Approach of Future is exactly the same approach as that used by ProgressListener; code that sets up the work is responsible for taking responsibility about its flow control.
jgarnett: I notice that SwingWorker now implements Future
jgarnett: so that may infact show a good approach.
aaime: but it keeps separate control and notification
aaime: you need to listeners for progress
aaime: (progress tracking)
jgarnett: http://java.sun.com/javase/6/docs/api/javax/swing/SwingWorker.html shows how to do Future and a Swing Progress bar together.
desruisseaux: We submit a Callable (or Runnable) object to an Executor, which will start the process in whatever thread it wish. Executor gives us in return a Future object that we can use for cancelling or getting the result.
aaime: would that fit in the Eclipse process control mechanism?
aaime: (with GeoServer I'm hands free, I can use whatever java API)
jgarnett: we still need a bit of glue code; for when the progress & future is delegated to other code (does anyone know what I am talking about here?)
jgarnett: aaime eclipse Job is very simple (on the level of Runnable + ProgressMonitor)
jgarnett: so we can make it work with whatever we end up with
jgarnett: I am more concerned about some of the process engines; I am not aware of anyone that uses Future yet.
desruisseaux: I use it.
desruisseaux: MosaicImageWriter use it in order to write many tiles in parallel.
sfarber: I used it too, to do pipelining so as to avoid the geoserver overload bug. It was pretty easy to get ahold of, and sort-of 'just worked' for the rather complex threading tasks that were put in front of it.
desruisseaux: I'm considering to use it in MosaicImageReader as well (reads many tiles in parallel) but this is more tricky.
jgarnett: still focus is on the Java programmer making processes; I would much rather only the workflow engine writer has to be smart (cause they only need to do it once)
simboss: hi guys, sorry I am late
jgarnett: martin and saul; do you use ProgressListener; or any other glue code in geoapi / geotools ?
aaime: sfarber, what was that? "geoserver oveload bug"? Never heard of it...
sfarber: It's the bug you've just found with DRobinson.
sfarber: (I'm pretty sure)
desruisseaux: In the case of MosaicImageWriter, I use ImageWriteListener (forgot the exact name) since it is the listener I'm supposed to use. But the principle is close to identicaL.
jgarnett: okay
aaime: (sfarber, sorry, where is the patch for that?? )
jgarnett: so martin we will look at this; and revise the proposal if we can make it work.
sfarber: jgarnett: no I haven't used the geotools 'progressListener' class before. But I've used other versions of the same concept.
jgarnett: I don't see any downchecks right now.
jgarnett: as for beans vs iso parameters; we are pretty stuck on that stuff - they both don't meet our requirements.
desruisseaux: 10 minutes left to the meeting...
desruisseaux: Well, I suggest to focus on one topic at time.
jgarnett: yeah lets move on; take the rest to email - good discussion however. Should we call a breakout IRC on this? because we gotta get moving...
desruisseaux: Could we start with Future, and revisit parameter later?
gdavis: well i cant move forward without some decisions on all these things...
jgarnett: yes; what we have now works for parameter.
jgarnett: so we can proceed with what we have now.
gdavis: ok
jgarnett: 3) maven 2.0.9
jgarnett: martin over to you?
gdavis: have we pretty much decided to use runnable then?
desruisseaux: I would said that the decision for now is to try to fit into java.util.concurrent for everything except parameters.
desruisseaux: java.util.concurrent said nothing about parameters, so we can revisit this issue later.
desruisseaux: So yes, lets try to use either Runnable or Callable (at your choice)
gdavis: ok
acuster: what are the processes for?
desruisseaux: http://java.sun.com/javase/6/docs/api/java/util/concurrent/Callable.html
acuster: i.e. how complex?
desruisseaux: Maven 2.0.9
Eclesia: acuster: http://docs.codehaus.org/display/GEOTOOLS/Process+proposal
simboss: guys I would ask some feedback on the RS proposal before we close the meeting since it has been floating around for a while now
desruisseaux: Cédric tried a build and got no problem
jgarnett: grab an agenda item?
Eclesia: ther are exemples at the beginning of the page
jgarnett ha scelto come argomento: 0) what is up 1) SoC 2) Process 3) Maven 2.0.9 4) proposals
simboss: thx
desruisseaux: Any objection if we put Maven 2.0.9 as a requirement?
desruisseaux: Doing so (after removing the plugins version that are now declared by Maven) produces an upgrate of a bunch of plugins.
desruisseaux: We are using some olds plugins versions.
desruisseaux: Letting Maven select the plugins versions may help us to get the upgrate them from time to time.
acuster: I don't object but I'd like to stop maven creep
desruisseaux: (typo: to update them)
acuster: i'm tired of everyone being on different mavens and not knowing why stuff is broken
DruidSmith ha abbandonato la stanza (quit: Read error: 110 (Connection timed out)).
desruisseaux: (for info, Andrian may be refering to aggregated javadoc not working when building with Java 5. It work with Java 6 only and nobody known why)
aaime: on 2.4.x it seems to works with java5 (that's how I build the aggregated jdocs for 2.4.x releases)
desruisseaux: It was used to work before, but Adrian has spent one days trying to get it on trunk, and the only way that seems to work is with Java 6...

desruisseaux: Nevertheless, my hope is that nailing down the pluging to the versions "recommanded" by Maven releases starting at Maven 2.0.9 may help to make the build a little bit less chaotic.
desruisseaux: (this is just a hope though)
desruisseaux: By chaotic I means things that was used to work and doesn't work anymore like javadoc...
desruisseaux: Any opinions?
sfarber: desruisseaux and acuster: can you try your changes before requiring this?
desruisseaux: Yes we tried.
simboss: btw, as a side note maven >= 2.0.8 has a few interesting bug fixes for doing offline builds
sfarber: I mean, just make the local mods to the pom.xml files, run it with maven 2.0.9 and see if it works!
desruisseaux: Yes we tries and it worked.
simboss: when snapshots are involved
desruisseaux: (typo we tried).
sfarber: ok, so the data point is:
jpfiset ha abbandonato la stanza.
sfarber: * maven mvn >=2.0.9 + martin and acuster's changes = working javadocs and building
acuster: nope, not so lucky
sfarber: I think that's clearer than "my hope is that nailing down the pluging to the versions "recommanded" by Maven releases starting at Maven 2.0.9 may help to make the build a little bit less chaotic."
desruisseaux: by "it worked" I means the build is successful, but aggregated javadoc is still working only with java 6.
desruisseaux: However I feel it as a step in the good direction.
aaime: hmmm... what improvements do we get (solid ones, things that did not work before and work now, or things that work faster)?
desruisseaux: None I can see right now.
aaime: (since experience is showing that we find out issues only when everybody switches)
desruisseaux: Simplier pom.xml.
acuster: what version of maven is cannonical today?
***acuster bets there are many
acuster: I was on 2.0.8
aaime: me too
simboss: same here
aaime: what worries me is not really switching to 2.0.9, it's changing the pom
desruisseaux: Oh I forgot! One possible benefit.
desruisseaux: After the Maven plugin upgrates, we got warning telling us that some of our modules will not build anymore in a future Maven version.
aaime: erk
desruisseaux: We got the warning after the plugin upgrate, not the maven upgrate itself.
jgarnett: back
desruisseaux: The warnings tell us what need to be reviewed and maybe modified in our pom.xml.
jgarnett: I just updated from maven 2.0.5 to 2.0.8 in the last month.
desruisseaux: So having too old plugins is maybe not a good idea.
acuster: martin can we split this out?
desruisseaux: May be easier to upgrates the plugins a little bit more frequently, and relying on Maven 2.0.9 and future version for that may make it easier.
acuster: ask for concesus on the move to 2.0.9
acuster: then ask for what the feeling is for changing the pom.xml?
acuster: and when downstream users have time to test builds
desruisseaux: Fine for me.
desruisseaux: So the proposal it: ask peoples to move to maven 2.0.9 now but do not update the pom.xml yet
aaime: Martin, maybe create a patch, a jira issue, and then ask people to try it out
desruisseaux: And update the pom.xml a little bit later?
desruisseaux: Okay.
aaime: works for me
acuster: anyone object to moving to 2.0.9?
aaime: (thought without a changed pom no-one will really forced to move to 2.0.9 I guess)
acuster: going, going ...
jgarnett: thinking
jgarnett: I am willing to try it
The [i=3f5eed82@gateway/web/ajax/mibbit.com/x-7300a1f6eebe1f03] è entrato nella stanza.
jgarnett: can we do another thing when we try on the weekend; it to avoid downtime?
jgarnett: (or is everyone feeling lucky)
The ha abbandonato la stanza (quit: Client Quit).
aaime: Do we really have a maven version that people have to use? Afaik we just have a recommendation in the release guide?
DruidSmith [n=DruidSmi@pool-71-181-172-190.sctnpa.east.verizon.net] è entrato nella stanza.
jgarnett: occasionally our build just does not work; if you do not go with the maven version in the developers guide
jgarnett: (ie I just want to list what is tested and working)
desruisseaux: We will create a JIRA task tomorrow, ask volunter to try and maybe edit the pom.xml in a weekend if we got the permission to then.
desruisseaux: I'm done.
aaime: cool
acuster: good
acuster: btw,
acuster: I changed some javadoc stuff today
jgarnett: okay
jgarnett: meeting time is up
jgarnett: but I really wanted to hear from simboss and aaime about the proposal storm last week
acuster: as in using references to javadoc 5 not 1.4
jgarnett: do either of you want to take the floor?
acuster: just a heads up for anyone that notices things changed
aaime: jgarnett, sorry, my sql proposal is dead in the water implementation wise
simboss: jgarnett: just a reminder about the RS proposal
jgarnett: your sql proposal?
aaime: I'm on a paid project for the next 2 weeks
aaime: sld proposal, sorry
jgarnett: okay
Eclesia: simboss : do you follow SE1.1 or a mix between SLD1.0 and SE ?
simboss: SE 1.1 and SLD 1.0
simboss: are basically the same thing
jgarnett: We checked SE1.1 as part of the review of his proposal.
simboss: as far as rasterSymbolizer is involved
jgarnett: simboss do you have everything you need? ie enough votes ... enough discussion etc...
simboss: actually
jgarnett: (http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support)
simboss: I wanted to ask martin if he had some time to review a bit the the proposal
jgarnett: I only see two votes ...
simboss: since last time he expressed some cocnerns
simboss: I think that we are at a stage now
simboss: that we can port to trunk
simboss: and narrow down remainig concerns while there
simboss: this thing has been sitting on a branch for enough time
simboss: risk is to lose it
sfarber: I really agree with simboss here.
sfarber: And I really need the RS work for better SDE raster support.
jgarnett: so what do we need votes from aaime, jdeolive, martin and yourself?
jdeolive: i know little of it... but i looked it over and like dit
jdeolive: +1 from me
aaime: sorry, I did not manage to review the classes that's why I did not vote
jgarnett: sweet
jgarnett: +0 then aaime?
simboss: as I say in the proposal I really need people to test this work
simboss: the combinations for RasterSymbolizer are a lot
simboss: even thought the code coverage is >= 70%
jgarnett: simboss I have paid work to make a bit of a user interface for this stuff
simboss: I would like to have someone like sfarber hitting on it
jgarnett: the moment I have that I will get more testing than I know what to do with.
desruisseaux: Just a quick note: Eclesia is working on expressing Symbology Encoding 1.1 as GeoAPI interfaces. He feels that such SE interfaces would naturally fit in a raster symbolizer. He asks if there is any chance to wait for one week until the SE 1.1 specifications is expressed as GeoAPI interfaces?
simboss: cool
jgarnett: martin I checked against the SE 1.1 proposal; there are no new ideas here for RS work.
simboss: the interface for RasterSymbolizer are the same
jgarnett: So Eclesia's work should not effect this.
Eclesia: you forget the function problem
aaime: (or, if it affects it, changes are that it will break gt2 api?)
simboss: but I am keen to check eclesia work (especially the widgets )
desruisseaux: It would effect if we wish to use a common set of interfaces
jgarnett: Eclesia; I don't think there is a function problem; but we need to have this conversation on the geoapi list ...
simboss: is there a proposal for this?
Eclesia: SE clearly separate FeatureTypeStyle from coverageStyle at the beginning, and later in the specification a concept of Function is used
simboss: to have an idea about the impact?
Eclesia: and i haven't clearly defined this "function"
desruisseaux: Is there any chance that Simone could look at the proposed interfaces, comment, etc. and see if it would be doable to implement some of them?
jgarnett: aaime I hope to make geotools interfaces extend the geoapi ones; and unlike with filter not switch over.
Eclesia: I could comit what i've done so far on geoapi, simboss could have a look
desruisseaux: Note that it doesn't prevent Simone to move the work on trunk if he wish
jgarnett: Function is the same as Filter 1.1 function; but has the optional concept of a "default" value to use if the function implementation is not found (a very smart move). There is also a list of optional functions they recommend implementing.
simboss: what if we do this
simboss: I port to trunk
simboss: so that sfarber and jgarnett can start testing
simboss: and when eclesia is ready
aaime: I don't see why a proposal that has been in the works for month should be stopped by one that does not even have a wiki page (just my 2 cents)
simboss: I help with adapting
simboss: aaime +1
jgarnett: aaime you are correct; that is why I checked the SE 1.1 just to see if there was anything to learn.
jgarnett: (it not related to Eclesia's work; as part of reviewing Simone's work)
aaime: if the Eclesia work gets a successfull proposal we can adapt the raster symbolizer wokr
aaime: I think we'll have to adapt various other stuff (or not)?
simboss: aaime: that's why I asked for a proposal page
desruisseaux: Expressing ISO standars as interfaces and proposing a new set of interfaces (from our own mind) is not the same process...
aaime: there are a few things that are new in SE 1.1 so to handle those parsers, style factory, styled shape painter and whatnot will have to be changed
simboss: or does the proposal pain applies only to some people ;-( ?
aaime: ISO interfaces must be voted like anything else
simboss: (note that pain was not a typo )
desruisseaux: Andrea, if so it should be voted by OGC working group, not by us.
aaime: I won't allow the usage of geoapi to circumvent the proposal process
aaime: by us too
jgarnett: understood; traditionally we have adopted geoapi interfaces when they were ready. Just like with the feature proposal. Same deal here.
aaime: since gt2 is not giont to implement any random idea that comes up with geoapi
aaime: we're the only implementor
desruisseaux: Not accurate Andrea.
aaime: geoapi is just a way few people use to control gt2 in my vision
desruisseaux: Referencing: JScience
desruisseaux: Geometry: Geoxygen
simboss: geoxygne is quite dead,
aaime: nevertheless, implementing it must be a free choice
simboss: it is not hte best example ever
aaime: not an imposition
jgarnett: on the positive side we are trying to have more controls on the geoapi side; I don't want to see the project confused by interfaces without a public implementation again.
simboss: and I agree with aaime here
simboss: changing the interface should be strongly discussed
jgarnett: yep
jgarnett: um; this upgrade to SE has been on the technical debpt page for a long time
acuster: is geotools still aiming to implement OGC/ISO ?
desruisseaux: You means changing the interfaces in the RS proposal?
simboss: the most successfull FOSS4g libraries
jgarnett: I went over that plan with Eclesia a few weeks ago.
Eclesia: ok, so i'll do SE in geoapi and if it's not to far from geotools, will make an update? is that so ?
simboss: do not even implement most OGC interface
aaime: Eclesia, you make a proposal
aaime: just like everybody else does
Eclesia: i made a jira task in geoapi
aaime: far or close it's not the matter at stake
jgarnett: Eclesia I was recommending you update the geotools interfaces first; and then "pull up" the geoapi interfaces.
jgarnett: basically don't develop the geoapi interfaces in isolation directly from the specification.
Eclesia: it's geotools that must align on OGC specification not the contrary..
jgarnett: stay in geotools with the safety/sanity check of running code.
desruisseaux: I would said the opposite: right it as close of specification as possible. Only after see if we need to make extensions.
aaime: we do not "must", we choose, it's different
desruisseaux: (typo: write it as close...)
aaime: and choose == proposal + pmc vote
vheurteaux: simboss: one of the purpose of GT2 is to follow OGC interfaces no?
jgarnett: indeed; please note that geotools style objects have been checked against SLD 1.0; there will be a very small difference between them in SE 1.1. That difference is what we need to talk about.
vheurteaux: in my understanding it's why it jump from 1.x to 2.x
aaime: vherteaux, as long as they are sane and they don't break existing software, yes
jgarnett: perhaps because I performed the check of geotools style vs SLD 1.0 I am more comfortable?
aaime: but we're not OGC monkey
simboss: vheurteaux: to be honest 1> I do not care much about OGC interface 2> who decides when to switch?
simboss:
jgarnett: the PMC does; when we have a proposal to vote on.
simboss: jgarnett: exact OGC does not pay me
jgarnett: indeed; OGC (and thus GeoAPI) simply gives me food for thought.
aaime: switching to geoapi filter was one of these "follow ogc" decisions and we're still paying the consequences (or a badly managed transition)
jgarnett: When I like their thoughts and we have a proposal to implement; we go.
simboss: but anyway if Eclesia proposal is strong, I see no reason why we should not accept it
aaime: simboss++
jgarnett: aaime not too sure about that; we had solid WFS 1.1. needs; the problems we encountered were due to scope; and we tried to inflict the process proposal thing on geotools to cut down on that.
jgarnett: lets give the proposal process a chance to handle SE 1.1
jgarnett: (it will be a good test)
aaime: that is my whole point
desruisseaux: Referencing, after the switch to ISO 19111, has been one of the most stable module in geotools because we made a big effort to follow ISO specification. Those guys have more expertise than we have and their specification are ofter wiser than what we would have imagined on our own. A module is more stable if it has been designed in such a way that it can meet needs that we even didn't...
desruisseaux: ...imagined today, and following the work of real expert groups help us a lot to reach this goal.
simboss: it is just that switching interfaces is, IMHO, a bit step and it is good to at least know everybodu about it
aaime: I'm not against ISO or OGC per se
aaime: I'm just saying that regardeless where proposals do come from, they have to be discussed
simboss: guys: sorry to interrupt but unless I see a proposal
simboss: I will vote -1 regardless of the idea
simboss: because I don't see why I had to spend night to refactor
simboss: my work
simboss: and wait for approval
aaime: desrisseaux, "real expert group" have shown to be able and make very silly decisions due to lack or real world involvement
desruisseaux: Sometime they fail andrea, but often they success. You should also admit that.
simboss: otherwise
aaime: j2ee v2, wcs 1.0 -> 1.1 transition, inability to handle real world symbolization are just a few examples
simboss: IMHO all this dioscussion is pure phylosophy
simboss: changes require proposal and vote
desruisseaux: ISO 19111 is much wiser than what I would have imagined on my own.
aaime: of how an "expert group" can screw up big time
desruisseaux: ISO 19107 is way above the capacity of my little brain.
jgarnett: hrm; this is a good discussion; but I would like to bring the meeting to a close soon. I am looking forward to Eclesia's work; geoapi really needs the help and I am glad someone is getting a chance to fix it up.
aaime: which is very very scary by itself, if not even you can handle it, who's going to be able and use it?
aaime: desriusseaux, if you don't like it this way, make a proposal asking that gt2 follows blindly whatever ISO or OGC thing comes out and let's count the votes pro or cons
jgarnett: Eclesia I will be glad to review your work; Martin said you had a couple of weeks on this topic? From my own experience with ISO19107 it may take a bit longer.
desruisseaux: ISO 19107 is hard because it try to adress a hard topic. The fact that the earth is spherical and 3D really brings a lot of complication - but this is real world and handling that fact needs a much higher expertise than I have...
jgarnett: you are correct martin; SE 1.1. is easier
Eclesia: My work is on SE1.1 , ISO19117 portrayal and GO-1
jgarnett: but often what took me some time was thinking through how to make good consistent interfaces from these specifications.
jgarnett: fun fun
aaime: My point is not to bash OGC or ISO, it's jsut that anything using them is no different than any other work -> it needs a positively voted proposal
acuster: hg, bzr or git will render this whole discussion irrelveant
aaime: acuster, if you want to fork gt2 you don't need any of them?
***Eclesia is not making this for fun, we have needs behind those specifications
jgarnett: agreed aaime; it is how we run the project. I give equal weight to designs that have shown success (success may be running code that is a joy to use; or success may be a ISO stamp of approval showing that a group has been able to sort through more compromizes than I can image....)
acuster: open source is a fork
aaime: if you want to make an official gt2 release with that stuff otherwise the tools do not help
aaime: a proposal is still needed
acuster: proposals are only needed to change existing api
acuster: as per the developer docs
aaime: right
vheurteaux: just to understand things guys
jgarnett: right; the existing api in this case is GeoTools LineSymbolizer; we would be asking it to extend a geoapi class.
acuster: but I don't care one way or another, it's a good few years before we're even close to having working code
vheurteaux: is GeoAPI dependant to GT ?
aaime: no
acuster: i.e. a GIS
aaime: it's not
aaime: but GT uses it so we have to decide wheter we do follow it or not
aaime: if Spring screws up big time in 3.0 geoserver will stop using it
vheurteaux: ok, but Eclesia is working only on the GeoAPI part ATM
aaime: vherteaux, and that is the business of whoever is managing geoapi
aaime: the proposal will be needed when you want to implement those interfaces in gt2
jgarnett: vhrurteaux; if I was mangaging I would ask Eclesia to start from GeoTools interfaces (since they represent an encoding of SLD 1.0 that works and has been checked)
vheurteaux: so the proposal must be done in order to be used in a GT project (ie. RS)
jgarnett: add in the new stuff for SLD 1.1
jgarnett: and pull up all the get methods into a super class in geoapi.
jgarnett: (low risk all around)
aaime: the proposal must be made even when gt2 starts using geoapi sld stuff as well
aaime: since it changes the gt2 api
Eclesia: my actually classe are a merge between geoapi SLD and GeoTools styling
jgarnett: then I would present a change proposal;
jgarnett: - to add the SE 1.1 methods to getools
jgarnett: - to add in the extends section
vheurteaux: ok I see...
jgarnett: Eclesia; yes - and the two are almost identical; except where geoapi screwed up (by following a version of SLD that was never published)
jgarnett: ie geoapi has two mistakes: a version of SLD that was never published; and two copies of the style interfaces (one based around Feature, and one based around Graphic). We can do better ... and it is a nice bit of work.
desruisseaux: The style interfaces in Graphic should probably be removed.
jgarnett: (so far from talking to eclesia I see two "interesting" sections for the proposal; with actual new ideas that will be of benifit to Filter, and the idea of inline graphics)
desruisseaux: We already talked about that issue at OGC meeting.
jgarnett: yes;
jgarnett: but this is turning into a geoapi meeting.
aaime: oh well, the issues are serious
jgarnett: and we have kept the geotools meeting going on longer than I can personally aford to give it.
jgarnett: aaime; so serious it is worth starting from the proven geotools base.
jgarnett: (which is holding up very well; I just went over it with a Java 5 stick last month)
jgarnett: http://docs.codehaus.org/display/GEOTOOLS/Technical+Debt#TechnicalDebt-UpgradeStyletoSLD1.1
simboss: guys sorry bother but could we come to a conclusion ?
jgarnett: conclusion; meeting over; I would like to review Eclesia's work on the geoapi list.
simboss: yeah and the RS proposal?
jgarnett: and I am confident that the most this will do to geotools is give us SE1.1.
jgarnett: RS proposal is a seperate matter; you have enough votes.
jgarnett: I checked it against SE 1.1
aaime: indeed, without -1 on it
aaime: you can start merging it
jgarnett: (and martin has a chance to do that as well; since he has not voted yet)
aaime: 3 days have passed since the proposal has been upgraded, no?
simboss: even a bit more
jgarnett: yep; means you can commit; the window for feedback is a little longer - but not much.
aaime: (was that two weeks?)
simboss: Eclesia: is there any chance you could wirte something about what you are doing
Eclesia: (two weeks not much compare to more than 3months for the process )
sfarber ha abbandonato la stanza.
Eclesia: you can review the jira task simboss
simboss: eclesia
Eclesia: i'll commit in the next days
aaime: Eclesia, you're right, but yet you could have started working on it after the required time passed
simboss: sorry
simboss: but looking at jira
simboss: is something I will not do
aaime: there's a reason we put a limit of 2 weeks on feedback
aaime: to avoid proposals being stalled by lack of feedback
simboss: because I have no time
Eclesia: i'll remember that, you can sure of it
simboss: just a smal page with some directions would help
aaime: the proposal process is there on a wiki page for everybody to read
simboss: exact
aaime: I'm not popping up rules out of a magic hat
acuster: proposals are great
aaime: http://docs.codehaus.org/display/GEOT/GeoTools+change+proposal
aaime: I would not go so far as to say they are great but they work better than not having them
aaime: from the wiki page:
aaime: "To avoid stagnation by lack of interest/time from community members the following assurances are provided:
aaime: svn access for changes is granted within 3 days from the proposal
aaime: proposal is accepted 'automatically' within 15 days (unless objections are raised) "
jgarnett: Eclesia you can start with the plan I had to upgrade Style to SLD 1.1 if you want
acuster: they are the closest we ever get to design documents for now