Blog from Jan 21, 2008

IRC Logs January 21st


  1. What's UP?
  2. Ggt legal
  3. emf models
  4. info
  5. osgeo report 2007
  6. shapefile

Eclesia: hello jgarnett
Eclesia: jgarnett: is there a meeting today?
vheurteaux left the room (quit: Read error: 104 (Connection reset by peer)).
jdeolive: hi Eclesia not sure since its a holiday in the states...
Eclesia: ok
jdeolive left the room (quit: Remote closed the connection).
jdeolive entered the room.
cholmes left the room (quit: ).
desruisseaux entered the room.
acuster entered the room.
desruisseaux: CodeHaus wiki is up, down, up, down again, up, down...
desruisseaux: like wheater
jdeolive: haha, i know... it has been flakey
jdeolive: so are we having a meeting today?
jgarnett: yep
jdeolive: cool
jgarnett: usually people trickle in about now.
jdeolive: its a holiday in the U.S. today
jgarnett: so how can I work on geotools? do I need to build geoserver ...
acuster: down
jdeolive: jgarnett: no
acuster: jgarnett, I have more geom questions for you...
jdeolive: clear out .m2/repository/net/opengis/ows
jdeolive: it should download the new ows jar
acuster: jdeolive, I have an xml parser question for you but it's at the office
jgarnett: thanks justin I will try that.
jdeolive: acuster: cool, fire it off on the list if you like
acuster has changed the topic to: Weekly IRC: 0. what's UP? 1. gt legal
jdeolive has changed the topic to: Weekly IRC: 0. what's UP? 1. gt legal 2. emf models
jdeolive: do you guys actually mind if 2 goes before 1?
jdeolive: i dont think i can stay for the entire meeting
***acuster offers codehaus a lollipop so it will wake up
acuster: yes, because 1 needs no discussion but a consensus
jdeolive: ok
acuster: we'll start early and move quickly
jgarnett has changed the topic to: Weekly IRC: 0. what's UP? 1. gt legal 2. emf models 3. info 4. osgeo report 2007
acuster: there are only three pmc?
Jesse_Eichar entered the room.
jgarnett: simone is sending email; so he should be around
jgarnett: gabriel is on skype; apaprently having IRC troubles
acuster: everyone should read:
acuster: because I know they have not yet
jgarnett: acuster do you want to move your topic later in the meeting; incase we have more people by then?
***jdeolive is waiting for codehaus...
desruisseaux: I have read it at a time where CodeHaus was up. It was good old time...
desruisseaux: (typo: at a time when...)
acuster: jgarnett, let's get a show of hands early and one late
vheurteaux entered the room.
jgarnett: gabriel is resetting his router; may join us soon.
Jesse_Eichar: 5) shapefile
jgarnett has changed the topic to: Weekly IRC: 0. what's UP? 1. gt legal 2. emf models 3. info 4. osgeo report 2007 5. shapefile
acuster: shall we start?
jgarnett: yep!
jgarnett: 0) what is UP!
jgarnett: jgarnett; trying to make sure the build is good so I can fix udig trunk; really should be doing other work but what the heck.
acuster: acuster — trying to map out the work for iso geometry; slowly figuring out ebRIM and JCR
desruisseaux: Martin: again and again IFREMER work (actually it may be of interest for Simone: working on "coverage views" in order to fix an issue I have with resampling)
***jdeolive has h2 passing all wfs cite tests
acuster: congrats jdeolive !
jdeolive: thanks (smile)
Jesse_Eichar: shapefile is working for me on windows and osx.
ggesquiere entered the room.
acuster: congrats jesse!
acuster: next?
jgarnett: okay lets move on ...
jgarnett: 1. gt legal
aaime entered the room.
acuster: So the proposal is to move forward on assigning copyright to OSGeo
acuster: as seen:
acuster: when codehaus wakes back up
acuster: Essentially today I'd like to get a show of everyone's feelings
groldan n=groldan@ entered the room.
aaime: Sigh, codehaus confluence lately has been a pain (hi all btw)
jgarnett: so last week we asked; and I am still good to go on this one.
jgarnett: just waiting for you to call the vote (smile)
groldan: hi, sorry I'm late, connection problems
acuster: +1 is "I'm willing to assign my copyright to OSGeo" 0 is "I don't care" -1 is "no way josé"
aaime: acuster, jgarnett
aaime: that page looks fine but
acuster: note it's not a vote
aaime: does not talk about companies
acuster: aaime, what would you like to know?
aaime: many of us have copyrights that have been assigned to companies
acuster: companies are merely another contributor
aaime: whatever I do on geoserver is topp own's
acuster: TOPP has said they are on board,
acuster: as did Refractions
acuster: last I checked with cholmes and pramsey
aaime: sure, just found it odd that companies were not mentioned
acuster: sorry, my fault.
groldan: sorry, page link again?
***acuster is exhausted by it all
groldan: thanks Adrian
jgarnett: acuster - we are almost done.
acuster: so what is everyone's personal feeling?
acuster: would you do it?
aaime: I'm good to go
acuster: +1
desruisseaux: +1 for giving copyright to OSGEO
acuster: Eclesia, you too eh?
jdeolive: +1
acuster: aaime, you also contribute on your own time, no?
jgarnett: jgarnett+1
aaime: indeed
aaime: (I'm good to go == +1)
acuster: Jesse_Eichar, ? mgrant ? groldan ? Eclesia ?
Jesse_Eichar: +0
groldan: +1
acuster: okay, so that's a show of hands
acuster: seems like no one objects so I suggest we go forward with it
acuster: each of you can start to print out the pdf and send it to OSGeo
desruisseaux: Sure. Can we write down the name of those who said +1 on the above-cited page?
jgarnett: so what happens next; we start working on a letter to contributors?
***mgrant peeks in, but is just monitoring geotools for personal interest (smile)
jgarnett: martin I will do that if your run the meeting for a moment.
acuster: There is one other decision that can be a vote if the PMC wants to
acuster: and that's how we will treat future SVN contributors
pc entered the room.
acuster: we can force them to contribute (c) which is mean but keeps the library clean
acuster: or we can accept code licensed under the lgpl
acuster: we would only need to document the latter
acuster: So I'm punting that decision to you PMC members
desruisseaux: I would be tempted to give SVN write access only to those who signed the agreement. It may looks rude, but I believe that keeping the code a little bit cleaner would benefit to GeoTools.
acuster: jgarnett, and yes, anyone can write a "We active contributors are going to give our (c) to OSGeo, why don't you?"
acuster: and with that I am done
acuster: jdeolive, you're up
jgarnett: okay I will write the letter.
jdeolive: cool
acuster: thanks jody
jdeolive: 2. emf models
desruisseaux: On the question raised by Adrian (SVN), any comment?
jdeolive: currently there are xml modules in geotools that depend on emf generated models
jdeolive: for wfs and ows
jdeolive: currently those models live in geoserver
jdeolive: it makes sense to move them to geotools
jdeolive: but i wanted to get peoples thoughts on adding generated code into geoserver
jdeolive: and no... we cant generate them everry time we build
groldan: into geotools you mean
jdeolive: sorry, generated code into "geotools"
jdeolive: (smile)
aaime: generation is a sort of a mix between working with an eclipse plugins and making manual adjustmetns
acuster: jdeolive, when you decided on ecore, did you consider the other binding approaches like JAXB?
desruisseaux: Can we keep generated code in an "unsupported" module for now?
jdeolive: acuster: yes, i did some extensive research
jdeolive: jaxb choked on gml3
jdeolive: understandably
acuster: it's too flexible?
acuster: s/it/gml schemas are
jdeolive: gml schemas are insane
jdeolive: also
jdeolive: emf has some nice things about its api... like fast reflection
***acuster does not understand the technology much but emf seems like the best piece of eclipse
jdeolive: however i have used jaxb before to generate simpler models
jdeolive: and it works ok
jdeolive: to answer desruisseaux
jdeolive: we could put them in unsupported... but then some extensions wold depend on unsupported modules
jgarnett: acuster++ you are correct; it is sad that eclipse is in the name as this really is the product of a very smart developer throwing out a lot of UML and keeping the good bits.
groldan: and also the wfs plugin would have to be moved to unsupported
jdeolive: plus i think it makes sense to include the module as part of its associated project...
groldan: which is not that unfair?
acuster: why don't we do a round or two as unsupported?
aaime: In fact GeoServer uses a few of unsupported moules
jdeolive: also... i would be fine with throwing these in a third party project
acuster: seems like a good idea, so 'supported' is rock solid stuff
aaime: I'm not against that, provided that the criteria for putting them into unsupported
aaime: is that they are "new", not that they depend on emf
acuster: +1
jgarnett: I would be fine with this code in unsupported for a while (since this is central to the geotools wfs story); but I would like to see this move to supported and not lurk for years (cough oracle) as something people are scared to touch.
aaime: One thing thought... these modules are basically test-less because there is nothign to test
jdeolive: correct
aaime: they are pure object models
aaime: no logic
jdeolive: yup
aaime: just data structure
acuster: are there docs?
aaime: the xsd is the doc (smile)
jdeolive: ha, well put aaime
jdeolive: there is also the spec (smile)
aaime: the emf models are a pure reflection of the xsd you generated them from
aaime: it's just the object model for a certain xsd
acuster: well, they deserve unsupported for that alone
jgarnett: still it would be good to have a test case that confirms the dependencies are in order; would rather find that out at build time.
aaime: acuster, they will never have docs in that sense
aaime: unless you spend time documenting them
acuster: because we want mortals to have pointers to figure out what's going on
acuster: how to generate the object model
acuster: where the schemas are
aaime: ah ok, that is a different story
acuster: all the stuff that you know cold now but that I don't
aaime: I agree we need those
aaime: I was speaking about javadocs
acuster: javadocs are not docs
jgarnett: Can I confirm that the generated code is not ugly? Some of our compition has a lost of their library generated ( ... there are not going to be an GML_OBJECT classes are there?
aaime: (thought I believe part of them are generated from the xsd annotations?)
jdeolive: what about the third party library idea?
jdeolive: it would be somethign like geoapi
aaime: acuster, I beg to disagree on the "javadocs are not docs"... I learnt most of what I know about java from javadocs...
jdeolive: but a collection of emf generated ogc models
acuster: aaime, can you tell me what a datum is? Translating from the real world into java is a key piece of docs
aaime: Yet another headache to upgrade each time it's changed (like geoapi)?
aaime: maybe not?
jgarnett: justin I get an offer to join one of those projects ever year.
desruisseaux: I tend to dislike automatically generated classes because they are often ugly, which is why I have a preference for keeping them "hiden" if we can. But I understand that there is pragmatic choices...
acuster: javadocs simplify reading the code
aaime: acuster, agreed
aaime: desriusseaux, there is no way to keep these models hidden afaik
acuster: jdeolive, I don't understand, now you are suggesting not to include emf stuff in geotools?
aaime: more than one module uses them directly
jdeolive: acuster: correct, instead depend on them as they were part of another library
jdeolive: actually that is the situtatoin today
aaime: acuster, since it seems they are not very much welcomed (wink)
jdeolive: they are part of geoserver
acuster: who is not welcoming?
acuster: martin is hesitant
desruisseaux: I do not object
acuster: and his suggestion for 'unsupported' seems resonable
acuster: but, as he says, ...
acuster: jody is all for it
acuster: I'm for it
acuster: gabriel, you and justin are presumably for whatever it is you are asking for
jdeolive: although i think this is a misuse of "unsupported" i could go for it too
acuster: 'un' is a negation of 'fully-supported'
acuster: not that it has no support
acuster: (smile)
groldan: afaik the models are interface + implementation. The interfaces does not impose much of an emf knowledge
groldan: except for some methods returning EList instead of plain List and the like?
aaime: the interfaces are emf dependent as well... right
jgarnett: Okay I see where we are stuck ....we are choosing between a new project (to hold generated code) and adding an unsupported module. Justin do you want some new category that is not unsupported; but not part of the core library?
aaime: extension? (wink)
jdeolive: aaime you took the words right out of my mouth (smile)
acuster: crutch
acuster: it's not an extension, being a building block
jdeolive: which is why i think it works well as a third party lib
acuster: but call it whatever you want
jgarnett: aside: traditionally we have not had the plugins depend on extention. The extention stuff is all optional being built on the core library + plugins.
jdeolive: i mean... yes it is another dependency... but thats the world we live in with maven
aaime: but we'll soon have wfs datastore depend on xml-xsd...
groldan: note if needed, the WFS module could depend on it just at runtime
aaime: hum... imho the situation could be simpler
jgarnett: justin I understand; but this stuff is going to be used a lot is it not. We already have sample-data; this is a similar idea (just used at runtime).
acuster: aaime, why not move xsd into the core then?
aaime: let's put wfs and emf models in unsupported for some time
groldan: right now there's a single facade class that holds all the emf knowledge in the wfs module, the rest is agnostic
aaime: and then move wfs in plugin back and emf models in core
jgarnett: aaime++
aaime: acuster, right, xml-xsd could be split into xsd-core -> library and the other things in plugin, that would seem reasonable as well
aaime: (and would fit with Jody's idea that nothing in plugin should depend on extensions)
jgarnett: justin are you happy with unsupported for today? so I can compile again... we can sort out moving it into the core library or extention later when wfs works.
acuster: you all should choose since you understand the dependencies
jdeolive: sure
jgarnett: cool
jgarnett: I best move us on ...
acuster: cool, and congrats on getting this far with it all
jgarnett: 3. Info
jgarnett: I found a collision of this idea with some hacks gabriel was doing in wfs; so I stepped it up a notch rather than see work duplicated.
acuster: who is needing this?
jgarnett: appologies to acuster for messing up maven; you will find your demo back in the mix.
groldan: right now udig is already using it at least for wfs
acuster: yes, I have although it crashes now but I'll fix that
jgarnett: udig needs this so we can get our datastore subclasses out of the project; wfs, postgis, oracle ... they all have this kind of code.
acuster: I don't understand why this is not a bigger effort something like a binding of WSDL
jgarnett: Eclesia was the origional motivation for doing it in 2.5.x rather than later; gabriel doing the same work was why it happened now.
acuster: but I'm not going to ask you to do more right now either
acuster: it merely seems like we will have to redo this properly down the road
jgarnett: thinking how to answer that; we are really just doing the same kind of thing as providing a "header" to a file. Datastore is starting to describe its contents. You are correct that down the road when we have a selection of formal metadata interfaces we will need to track more information; but we will not need to generate more information.
aaime: jgarnett, I don't have anything to object on the proposal at a first cursory look
jgarnett: ie this is data we are retrieving from shapefile headers; or table metadata, or WFS Capabilities.
aaime: I have a question thought
jgarnett: yep.
aaime: if we were to add informations about datastore capabilities
aaime: where would you put them?
acuster: and why is stuff like title not an InternationalString?
CIA-22: vmpazos * r28865 /udig/community/axios/udig-extensions/tags/0.1.0-rc4/: creating rc4
Jesse_Eichar: I've reviewed the work done on shapefile and it looks fine to me.
Jesse_Eichar: He put them on FeatureSource?
Jesse_Eichar: is that right?
aaime: Hmm... I was thinking more about what a datastore can or cannot do
Jesse_Eichar: Oh right
aaime: such as, write capabilities, locking capabilities, (fast) filtering capabilities ,...
Jesse_Eichar: there is one on datastore as well
aaime: Yeah, just wondering if the ServiceInfo is pure abstract description or if it's supposed to be a place for more, say, machine oriented information
Jesse_Eichar: Hmmm. Some of that would be nice. Right now it provides the information for a client to display information to the user.
aaime: (can't find the right words, but hope you get it)
acuster: so do we do this for now and warn that it's going to be re-visted?
Jesse_Eichar: Not so much machine oriented information.
jgarnett: aaime question #1. We have two options:
jgarnett: a) FilterCapabilieis is unque to the DataStore api (it defines limitations on a Query object). As such it should be a method on DataStore.
jgarnett: b) You can have a specific subclass of Info if you think it helps; ShapefileFileInfo is likely to have a few additional methods for example.
Jesse_Eichar: IMHO it is easier to keep it small and add later.
aaime: I agree
jgarnett: aaime question #2. It could be InternationalString; right now the javadocs say it is reporting the title in the current locale if available.
aaime: ok
aaime: anything else on the topic
aaime: want a vote now?
jgarnett: aaime / jesse I agree; lets see what information becomes useful over time. This set (dublin core + a bit more) is pretty well understood and has proven to be possible (which is more than some of our past attempts).
jgarnett: please; gabriel is making use of this code for a tuesday delivery.
aaime: tuesday as in... tomorrow??
jgarnett: jgarnett+1
groldan: right
jgarnett: (as far as he told me; hense my panic last week)
aaime: eek
aaime: +1
groldan: (smile)
acuster: eek
jgarnett: (on the bright side this represents uDig finally contributing back useful code to geotools now that we are on trunk)
aaime: one would say it's a bit rushed, but in fact udig has been testing these for a bit
***groldan is now crossing fingers for StreamingParser to the job for him
acuster: desruisseaux, groldan Jesse_Eichar ?
Jesse_Eichar: +1
acuster: if you are going to have a vote, vote.
groldan: +1 so
acuster: is that enough or does martin need to pay attention as well?
jgarnett: he does
aaime: GridCoverageReader
acuster: desruisseaux, desruisseaux, martin desruisseaux
jgarnett: and jdeolive (since we need PMC to carry this)
desruisseaux: oui
desruisseaux: oups: yes
jgarnett: moving on ...
aaime: (I guess everybody's French is up to "oui"... but don't get any further (wink) )
jgarnett: 4. Osgeo Report
jgarnett: They want to make a big report ...
jgarnett: as such they bothered me.
desruisseaux: (trying to catch up what happened ?????)
jgarnett: I just wrote this while watching the EMF discussion.
jgarnett: so please edit the page; correct me if I am wrong or send me email.
jgarnett: 2007 seems so long ago.
acuster: martin, the question is if you think the proposal should go through
jgarnett: 5) shapefile
Jesse_Eichar: Hi all
Jesse_Eichar: so I've done the first revision of the shapefile work.
jgarnett: we noticed! or hudson did
acuster: what was the work?
Jesse_Eichar: Seems to still work with uDig and geoserver trunk. Although geoserver has not been extensively tested but it works better that 2.5 at least with uDig as a client
Jesse_Eichar: 2 main things:
acuster: I know you told me last week but...
Jesse_Eichar: 1. Kill most of the duplicated code
aaime: (wow, did not know at RR you already had GS 2.5... can I have a look?)
Jesse_Eichar: hahs
Jesse_Eichar: 1.5 maybe
aaime: lol
jgarnett: nope 1.6 is what they are beta testing... is it 1.7 ?
jgarnett: I know trunk
Jesse_Eichar: 1.4 worked for uDig editing 1.5 didn't that I know
Jesse_Eichar: geoserver trunk with my changes works again.
aaime: good
aaime: too bad they are quite extensive
aaime: (would not mind a backport to 2.4 otherwise)
Jesse_Eichar: 2. I made a class for containing and providing access to the files.
aaime: and everythign is double checked on the "bastard platform from hell" right?
acuster: ah
Jesse_Eichar: it has a lock and all readers and writers to the files should go through that class.
Jesse_Eichar: Jody gave me a quick code review and didn't hate it (or hated it less than what was there before (tongue)
Jesse_Eichar: Next on my agenda is to add the new feature events to it
aaime: I did not review
aaime: but quick question
Jesse_Eichar: ok
aaime: are all files locked as a single lot?
jgarnett: he is modest; the code is fine. I need a few more utility functions (since there is a complicated process to check if we are using a File or URL). And I want to make sure the set is open ended (for things like sld and properites files)
Jesse_Eichar: yes
aaime: nice
Jesse_Eichar: The lock is a reentrant lock
Jesse_Eichar: so if you lock one you can hack away and no other thread can interrupt.
Jesse_Eichar: BUT (as I said in my email)
aaime: right, but what I meant is a little different
desruisseaux: On getInfo proposal, I have comment: getEnvelope() should returns the GeoAPI interface, not the JTS class
aaime: if thread a takes shp, thread b takes dbf, and no one gives up, we have a deadlock
desruisseaux: getKeywords() should returns a Collection<String> (List or Set at implementor choice), not a String[] array.
aaime: desriusseaux++
jgarnett: interesting point martin; right now it returns the GeoTools class ReferencedEnvelope (which is both a JTS Envelope and a GeoAPI BoundingBox)
Jesse_Eichar: That is done too. There is only one lock
Jesse_Eichar: its not a lock for each
desruisseaux: getTitle() as internationalString, but also getDescription()
Jesse_Eichar: windows can still deadlock
Jesse_Eichar: get a writer
Jesse_Eichar: then get a reader
Jesse_Eichar: then try to read
desruisseaux: Yes Jody, but the method signature in the interface is to returns a JTS envelope.
Jesse_Eichar: the writer locks the file and the reader cries.
jgarnett: (lets wait until after the meeting!)
aaime: Jesse, you should not be able to get a reader while someone is writing?
Jesse_Eichar: its windows man
Jesse_Eichar: not me
Jesse_Eichar: What you are supposed to do is:
Jesse_Eichar: get a File
Jesse_Eichar: (I think)
Jesse_Eichar: and use the same file OBJECT to get a reader and writer
Jesse_Eichar: I think right now the implementation creates new File objects
Jesse_Eichar: We might be able to fix that if we re-use the same files. This is just the way it was writeen previously
Jesse_Eichar: and I didn't think of this solution til now
Jesse_Eichar: But this isn't a problem normally
aaime: Well, an improvement is an improvement
Jesse_Eichar: because the ShapefileWriter and DBFWriter and... so on.. create a temporary file and write to that
aaime: but it would be nice if you dumped the above on an improvement jira issue
Jesse_Eichar: then on close the switch happens
Jesse_Eichar: ah ok will do
acuster: we done?
aaime: I guess so
acuster: it's 22:00+
jgarnett: yep; right on time - good work everyone.
jgarnett: I will post the logs; and go through ReferenceInfo with martin.
acuster: ciao all
jgarnett: note: I cannot build right now beacuse of SingleVolatileImageStrategy in Eclesias code?
jgarnett: thanks everyone; and great work acuster, jesse and justin.
pc: same here jody
acuster: Eclesia, ?
jgarnett: perhaps gabriel and I will be cool kids next week (when i stop breaking the build)