Just Justin and me about bleeding edge complex-features, fm, cpx branches
feb 27 22:03:10 <groldan> jdeolive, hi
feb 27 22:13:47 <jdeolive> hi gabriel
feb 27 22:13:51 <jdeolive> groldan
feb 27 22:13:58 <groldan> hey
feb 27 22:14:09 <groldan> how is it going?
feb 27 22:14:22 <jdeolive> good
feb 27 22:14:41 <jdeolive> i am merging changes from complex-features onto fm
feb 27 22:14:47 <groldan> wen I wasl almost done.. had no chance but making a wide api change... are you porting complex-features to fm?
feb 27 22:14:54 <jdeolive> yes
feb 27 22:15:13 <jdeolive> although the new geoapi changes conflict, but i am working around the conflicts
feb 27 22:15:17 <groldan> ok, may be you should freeze for a sec. I need to agree on a topic
feb 27 22:15:24 <jdeolive> ok
feb 27 22:15:55 <groldan> the point is: Attribute.getType() is insufficient, we need Attribute.getDescriptor(): AttributeDescriptor
feb 27 22:15:56 <groldan> instead
feb 27 22:16:04 <groldan> rationale:
feb 27 22:16:06 <jdeolive> i thought thats what it was
feb 27 22:16:50 <groldan> nope, we had only getType(), which means with the separation of concerns between attribute name and type name isnt enough
feb 27 22:16:54 <jdeolive> at least the latest version of the geoapi interfaces have that
feb 27 22:16:58 <groldan> actually getType() alone has no sense?
feb 27 22:17:18 <groldan> cool, let me check
feb 27 22:17:25 <jdeolive> there is a convenience method on Attribute, called type()
feb 27 22:17:37 <jdeolive> which is i would imageine is just shorthand for getDescriptor().getType()
feb 27 22:18:14 <groldan> meaning I'm moving all methods from AttributeFactory to create(AttributeDescriptor,...) instead of (AttributeType,...)
feb 27 22:19:00 <jdeolive> cool, that makes sense
feb 27 22:19:05 <groldan> ok, I missed the new interface has it, thats so cool
feb 27 22:19:16 <jdeolive> phew, glad i already picked up this one
feb 27 22:19:26 <jdeolive> i am actually starting to get the hang of this new model
feb 27 22:19:29 <groldan> I'm making the change on complex-features, may be it'll be better for you to get it from there?
feb 27 22:19:42 <jdeolive> yeah, i will merge it on, i will probably get a conflict but that is ok
feb 27 22:19:45 <jdeolive> go ahed
feb 27 22:19:53 <jdeolive> also, the build for geotools-cpx seems to be failing
feb 27 22:20:15 <groldan> yeah, I was fixing it as soon as I received the cc report
feb 27 22:20:23 <jdeolive> cool
feb 27 22:20:38 <groldan> one of the times I had to make a maven clean to pick the error in my dev environment
feb 27 22:20:54 <jdeolive> yup, good old maven
feb 27 22:21:31 <groldan> is there a meeting today? I thought the time was an hour sooner than now
feb 27 22:21:46 <jdeolive> noone really showed up
feb 27 22:21:48 <jdeolive> so i guess not
feb 27 22:22:02 <jdeolive> however, this discussion could have been our meeting 
feb 27 22:22:04 <groldan> well, not so bad, may be it gives me time to finish this
feb 27 22:22:13 <groldan> sure 
feb 27 22:22:37 <groldan> well, I'm happy this is the only remaining change
feb 27 22:22:43 <groldan> report:
feb 27 22:22:43 <jdeolive> so where is geoserver on the complex-stuff
feb 27 22:23:10 <groldan> - I have a _complex_ schema being mapped from sde to complexds
feb 27 22:23:26 <jdeolive> woohooo
feb 27 22:23:43 <groldan> - the schema is broken into various xsd's, complexds loads them alright, type reusing is ensured
feb 27 22:23:55 <-- eighty has quit (Remote closed the connection)
feb 27 22:24:12 <groldan> (nasty side effect is that I'm using TypeFactory as type and attributedescriptor registry)
feb 27 22:24:28 <groldan> but that could be fixed once we decide how to treat that issue
feb 27 22:24:34 <jdeolive> yeah, sounds minor
feb 27 22:25:00 --> eighty (n=eighty@adsl-71-132-249-0.dsl.pltn13.pacbell.net) has joined #geotools
feb 27 22:25:05 <groldan> -arcsde plugin is already ported to separate concerns between types and descriptors
feb 27 22:25:42 <jdeolive> cool
feb 27 22:25:48 <groldan> as a workaround, all the other datastores should be working as they used, 'cause an attribute descriptor is automatically created with the same name as the type
feb 27 22:26:15 <groldan> this is meant as temporal behavior, while in the process of porting datastores to "reuse type definitions"
feb 27 22:26:21 <groldan> sounds reasonable?
feb 27 22:26:27 <jdeolive> yup
feb 27 22:26:31 <jdeolive> sounds great
feb 27 22:26:54 <groldan> cool, we'll have to make a "datastore porting guide" on the wiki
feb 27 22:27:02 <jdeolive> definitley
feb 27 22:27:05 <jdeolive> right on on fm
feb 27 22:27:13 <jdeolive> i am going to ignore the datastore plugins
feb 27 22:27:14 <groldan> fortunately the change, though somewhat "wide", should be trivial
feb 27 22:27:23 <groldan> sure
feb 27 22:27:32 <jdeolive> until i get the core modules going
feb 27 22:27:46 <jdeolive> then we can call for help for the datastores and write up some docs
feb 27 22:28:18 <groldan> cool. After I get this "proof of concept" release out, I'll start helping you with the merge
feb 27 22:28:40 <jdeolive> good good, that release is definitley priority
feb 27 22:28:52 <jdeolive> so i am going to update, and get your latest changes
feb 27 22:28:52 <groldan> say, wednsday?
feb 27 22:29:07 <jdeolive> for release?
feb 27 22:29:10 <groldan> wai, have almost 200 files to commit
feb 27 22:29:19 <jdeolive> oh, ok
feb 27 22:29:22 <groldan> if god helps, release tomorrow
feb 27 22:30:18 <jdeolive> sure just let me know when you want to say go, and we can do it
feb 27 22:30:26 <jdeolive> although i dont have a release process set up for 1.4.x stuff yet
feb 27 22:30:33 <jdeolive> but it wont take me long to script it up
feb 27 22:30:48 <jdeolive> definitley be done by wednesday
feb 27 22:31:26 <groldan> well, I first will send bgs guys a self contained project demostrating their needs in unit tests
feb 27 22:32:10 <groldan> then will make it working on cpx and tell them to svn checkout and test with provided config.zip
feb 27 22:32:24 <groldan> not sure if a proper release is needed
feb 27 22:32:43 <groldan> I think the _release_ should go out from fm
feb 27 22:32:48 <jdeolive> alrighty
feb 27 22:33:03 <jdeolive> yeah that makes sense, complex-features is still a bit rough around the edges
feb 27 22:33:23 <groldan> exactly
feb 27 22:33:32 <CIA-10> jeichar * r18298 udig/plugins/ (9 files in 8 dirs): working on changing Layers View kind of squished now though
feb 27 22:33:39 <groldan> well, back to work, so you'll have the code to merge sooner.
feb 27 22:33:44 <groldan> ping me for any questions
feb 27 22:33:58 <jdeolive> sounds good, i am taking off for a couple of hours
feb 27 22:34:04 <groldan> also, could you upload this chatting as today's meeting?
feb 27 22:34:05 <jdeolive> later
feb 27 22:34:06 <groldan> ok
feb 27 22:34:10 <jdeolive> yes i will
1. Complex Feature Status
2. Shapefile FID Indexing
3. POJO DataStore
<groldan> cool, was worried about the time
<jdeolive> no problem
<groldan> there are agenda items so far?
<jdeolive> nope, lets start some
<jdeolive> 1) Complex Feature status
<Jesse_eichar> 2) FID indexing for shapefile
<jdeolive> anyone else?
<jdeolive> we can throw them on as they come up, i dont think anyone else is going to show
<jdeolive> i will start
<jdeolive> 1) Complex Feature Status
<jdeolive> so as you guys read from my email i have got the complex-features branch in geotools compiling in a 1.4 world
<jdeolive> and against the geoapi feature interfaces
<jdeolive> well a slightly out of date version of them, jody went and broke things on me
<groldan> yeah, just checked out, trying to build
<jdeolive> so i have been working against datestamped geoapi builds
<jdeolive> any luck?
<jdeolive> everything should be all commited up as of about half hour - hour ago
<groldan> maven complains, but it could be me. should I just "maven build"?
<jdeolive> yup
<jdeolive> i am sure i missed something though so i wont be suprised if it doesnt work
<jdeolive> what kind of errors are you getting
<groldan> Error parsing project.xml '/home/gabriel/workspaces/complex_merge/cpx/org.vfny.geoserver.gtlibs-cpx/project.xml'
<jdeolive> are you tring to build geoserver or geotools?
<groldan> geoserver cpx branch
<jdeolive> hmmm, oh, my bad, forgot to commit something
<groldan> np
<jdeolive> commiting now, you should be able to update and try again
<jdeolive> so to as where things are at
<jdeolive> i am unable to merge from geotools complex-features onto trunk
<groldan> its working
<jdeolive> the changes since the initial branching make the two pretty much incompatable
<jdeolive> so there might be some manual work to perform the merge
<groldan> yeah, I figure it out, so did you a manual merge?
<groldan> ah, ok
<jdeolive> so right now i still have geoserver building off the branch
<groldan> so you started branching trunk and manually applied differences from complex-features?
<jdeolive> nope, so far i have just been making changes to complex-features to get it to compile in a 1.4 world
<jdeolive> and against the new geoapi interfaces
<jdeolive> now we have to merge from complex-features onto trunk
<groldan> note: can you upload the following files to the online repository so maven can download them?:
<groldan> epsg-wkt-2.2.x-complex_branch.jar
<groldan> gml-2.2.x-complex_branch.jar
<groldan> property-2.2.x-complex_branch.jar
<groldan> shapefile-2.2.x-complex_branch.jar
<groldan> validation-2.2.x-complex_branch.jar
<groldan> complexds-2.2.x-complex_branch.jar
<jdeolive> yeah i can
<jdeolive> so the way the merge has gone so far is not desirable
<jdeolive> getting this stuff on trunk still represents quite a bit of work
<groldan> how far we are from being complete porting complex-features?/what do you need that I do?
<jdeolive> well i sent you that list of mofified files?
<jdeolive> if we could figure out where the major changes are, i would like to start there
<groldan> yes, is it ok if I apply changes and commit them or do you only need a review of most important changes?
<jdeolive> other things (like the filter api changes) I would like to do seperatley to avoid massive conflicts
<jdeolive> no go ahead, my only request is that you do not commit any java 1.5 code
<groldan> understood
<jdeolive> cool
<groldan> what do you mean by applying filter changes separately? branch the branch?
<jdeolive> well when I tried to do the merge using svn i got a conflict in every single filter file (~100 files)
<jdeolive> and all the changes are mostly just api changes (minus AttributeExpressionImpl, etc...)
<jdeolive> so i can save myself some pain just by using eclipse to refactor
<jdeolive> does that make sense?
<groldan> what's running on cpx is in line with geotools fm branch?
<jdeolive> not yet
<jdeolive> right now fm = trunk
<groldan> its from complex-features so?
<jdeolive> sorry not sure i understand
<groldan> I mean if the jars being used in cpx are built from complex-features or from fm
<jdeolive> complex-features
<jdeolive> i am uploading them to the refractions rackmount as we speak
<jdeolive> however feel free to build your own, they are synced up with svn now
<groldan> I'm getting the updates, nice
<jdeolive> i apologize for this being a bit confusing
<jdeolive> i would have liked to go directly from complex-features onto fm
<jdeolive> but with all the differences, and a deadline from rob to get a geoserver build up, i thought this was the least risky way
<jdeolive> get geoserver build up, then fix geotools
<groldan> no, its ok. so, in my understanding: cpx == trunk + complex-features
<groldan> complex-features backported to 1.4
<groldan> thats all
<jdeolive> yes
<jdeolive> so i just commited my last changes to geoserver, to get it to compile off of complex-features as you noted
<jdeolive> so now its pretty much testing time
<groldan> well, at least the geoserver side of things is easy. Do we'll get rob's release out of this schema and then go for Jody's modified geoapi interfaces in fm?
<jdeolive> yeah the geoserver changes were pretty trivial
<jdeolive> now i would like to test the complex stuff in geoserver
<jdeolive> not exactly too sure how to do that
<jdeolive> i guess i should read your user docs
<jdeolive> can i get to them off the geoserver experimental page?
<groldan> mmm... what about convering the complexds unit tests to http unit?
<jdeolive> definitley
<jdeolive> just not too sure what the requests for complex content and stuff look like, i guess they are mostly just normal requests
<jdeolive> however there is teh config setup
<jdeolive> which i have been figuring out as i go along
<groldan> some configuration info: http://docs.codehaus.org/display/GEOTOOLS/ComplexDataStore+Documentation
<jdeolive> do you think you could whip up a quick http unit tests as an example, then i can help write additional tests
<groldan> and yeah, requests behave as usual, just that you can include xpath expressions for addressing attributes
<jdeolive> cool, the docs look good at first glance, should be simple enough to get tests going
<groldan> though you already noted the xpath stuff still lacks namespace support
<jdeolive> i didn't see any tests from the geoserver branch you created when i did the merge
<jdeolive> correct?
<jdeolive> yeah, there are some assumptions going on, but we dont live in a perfect world yet
<groldan> we can setup the tests with a simple properties datastore so its easier to get them running
<jdeolive> yeah i noticed that is how the gt tests were setup, quite handy
<groldan> right and right.
<jdeolive> cool
<jdeolive> cool, things are going well
<jdeolive> so shall we continue this over email or offline
<groldan> so any change we divide work without steping on each other?
<jdeolive> yup sounds good
<groldan> (change == chance)
<jdeolive> how about i do the filter changes
<jdeolive> and you focus on the other classes that were changes
<jdeolive> changed
<jdeolive> but i think before that getting the geoserver tests going should be priority
<jdeolive> do you agree?
<groldan> ok.
<groldan> but I guess i'm not understanding something:
<groldan> cpx is already compiling and running against complex-features, so you mean setting up the geoserver tests and then start applying changes to fm?
<jdeolive> yes
<groldan> but run cpx against fm after this deadline
<groldan> cool, now I'm clear
<jdeolive> yes
<jdeolive> excellent
<groldan> do we let the meeting go ahead and continue this offline?
<jdeolive> sounds good, better yet it woul d be nice if we could start chatting on the devel list, let everyone else know what is going on
<groldan> alright
<jdeolive> alrighty, jesse_eichar, you are up
<jdeolive> 2) FID indexing for shapefile
<Jesse_eichar> ok
<Jesse_eichar> Currently making a feature query to a shapefile data data with a FID filter takes N time. where N is the number of features in the shapefile.
<Jesse_eichar> I'm making modification to the indexed-shapefile datastore so that it will perform FID filter queries in very nearly constant time.
<jdeolive> nice !!
<jdeolive> are you creating a new index for the fids?
<Jesse_eichar> yes.
<jdeolive> cool
<Jesse_eichar> It also changes a few things for example. before if you deleted a feature 1/2 of the way through the features all the FIDs of the remaining features would decrement by 1.
<Jesse_eichar> now they will stay the same at least between runs of the JVM.
<Jesse_eichar> The index is all file based so the memory footprint is not increased so don't worry there.
<jdeolive> sorry i dont understand, do you mean they will be same within a single instance of the jvm?
<jdeolive> and could change between instances? just that all the fids dont have to be update when you change one
<jdeolive> ?
<Jesse_eichar> What it means is the fid index may be deleted when the JVM is shut down depending on how many deletes have been made.
<jdeolive> ok i think i understand
<Jesse_eichar> If there have been many... say half of the features. Then the index is basically useless and should be regenerated.
<jdeolive> makes sense
Hi all. Just a reminder: news article up at http://freenode.net/news.shtml .... group registrations, staff channels, 2006-2007 fundraising .... have a great evening, and thank you for using freenode!
<Jesse_eichar> But I didn't want to do that in the middle of a run because it woudl invalidate all the fids the clients have obtained from the datastore.
<Jesse_eichar> hence. FID may be invalidated between JVM runs.
<jdeolive> ok, that makes sense, that is what i meant
<Jesse_eichar> ok
<jdeolive> did the old implementation change fids out from underneath people?
<Jesse_eichar> So I'm just about done now. I should get it on to trunk tomorrow ish.
<Jesse_eichar> Yes.
<jdeolive> cool
<jdeolive> sounds good
<Jesse_eichar> If a feature was deleted, say the first feature, then imediately all further fids are changed.
<Jesse_eichar> really caused us some headaches.
<jdeolive> yeah i can imagine, espceially for doing things like editing
<Jesse_eichar> exactly
<Jesse_eichar> That's all I have to say.
<jdeolive> cool
<Jesse_eichar> unless there are more questions.
<jdeolive> anyone have anything else?
<groldan> I would like to ask you about pojo ds
<Jesse_eichar> me?
<Jesse_eichar> or justin?
<groldan> yeah, Jesse
<Jesse_eichar> ok shoot
<groldan> are you going to make it, right?
<Jesse_eichar> Refractions is probably not me.
<Jesse_eichar> I'm pretty booked.
<Jesse_eichar> I'll most likely be a designer/consultant on it though.
<groldan> ah, sorry, I thought it was already assigned to you
<Jesse_eichar> nope not yet.
<groldan> ok, its just that I was working with hibernate and wondering if you thought on using it
<Jesse_eichar> I hadn't thought that much about it yet.
<Jesse_eichar> I don't know much about hibernate right now.
<jdeolive> that would be slick in our new geoserver world, spring has tonnes of integration utilties for hibernate
<jdeolive> but i really dont know tha tmuch about it either
<Jesse_eichar> we were going to abstract the persistence away from the datastore.
<groldan> ok, no worries, it may be worth a look though
<Jesse_eichar> so I think that should be one option but not necessarily the only one.
<groldan> my initial concerns about it was that it looked too much memory bound
<groldan> but actually it could be used in a streamed fashion, just like datastore api
<groldan> and you get caching and lazy loading out of the box
<Jesse_eichar> I agree. I never considered it a memory datastore at all.
<groldan> at the cost of extending it for spatial queries
<Jesse_eichar> I figured the backend could be a database/network/memory
<groldan> thanks, that's all. I'll try to be watching for it when the time comes, since I'm quite interested in the pojo ds
<groldan> that's all, thank you
1) RnD branch cleanup 2) osgeo votes are in ... and so is geotools 3) RnD updates(s) 4) Martin wants a plan 5) benchmarks against EJB and Hibernate
iant_ hi
jgarnett So I hope we can get the osgeo thing over and done with today
jdeolive hi guys
#geotools
jdeolive so official agenda?
jgarnett go ahead and start one 
jgarnett Email seems fun these days ... did anyone notice/care about my summary of the RND branches? I would like to kill off a bunch of them.
jgarnett 1) Kill RnD branches
jgarnett 2) osgeo votes are in ... now what?
jgarnett 3) RnD update(s)
jgarnett 4) Martin wants a plan (or has a plan?)
jgarnett anybody else? I am just making these up ...
iant_ I saw your email Jody
acuster for (1) a wiki page with monthly (or so) updates would be cool
acuster it would help triage email messages too, for those of us who don't follow uDig all day.
jgarnett On RnD land? I can write up a monthly news item.
jgarnett um geotools meeting, udig is its own ball of fun
acuster ah, yes, indeed
jgarnett (aside: not sure what the projection of fun is, unlikely to be CAD based)
jgarnett I should hope the news items (of all these projects covers the good parts)
jgarnett 1) Kill RnD branches
jgarnett Many of these RnD branches are dead and gone (and merged to trunk or failed and unloved)
jgarnett if you own one of them please clean up after it.
clint__ do you want to kill all the RnD branches
jgarnett No just the ones that are finished - like styling.
jgarnett chorner - you are done with styling right?
chorner correct
jgarnett okay can you respond to that email with the ones you have killed?
jgarnett anybody else? Justin I think I see some of your branches around stilll
jgarnett as far as I know only fm is active?
jgarnett Can expression be killed?
jdeolive yes
jgarnett okay can you kill it and respond to that thread please.
jdeolive sure
jgarnett jts16 - is that andreas old branch?
Jesse_eichar Yes.
Jesse_eichar It has been merged now.
jgarnett okay I will remove it then
jgarnett shapefileExp ?
jgarnett xdo-branch needs to stay alive for now
CIA-10 jgarnett jts16 * r18001 geotools/: thanks andrea worked merged into 2.1
CIA-10 jgarnett jdbc1-exp * r18002 geotools/: jdbc1 jdbc2 breakdown merged already
jgarnett 2) osgeo votes are in ... now what?
CIA-10 chorner stylish * r18003 geotools/: completed and merged Nov 2005
jgarnett I can answer my own question - they are asking for nominations. I will forward the email to geotools-devel
iant_ the foundation is in a sort of hold pattern re new projets just now
jgarnett iant_ now what?
iant_ the feeling is we can't set new projects until the membership is sorted 16th Feb I think
jgarnett ah hense the thrusday deadline for nominations...
iant_ However if the feeling of the PMC is in favour I'll go ahead and put us forward for project status
jgarnett okay, how did we do for voting? As far as I know we got most of the PMC votes in?
jgarnett How about module maintainers?
iant_ Jody I think your are mixing members (people) and projects
jgarnett how so?
iant_ There is no fixed plan yet for projects
jgarnett Sorry iant_ I was saying that the people nominatations are for 16th
jgarnett thus having a membership to worry about the projects
jgarnett (I was not articulate, but I don't think I am confused)
iant_ ok I misunderstood
jgarnett Is there anything more to talk about? Any prep we need to do, or should do?
iant_ I think we're good - the PMC "owns" the code, we have no IP issues that I'm aware of
clint__ 5) Benchmarks
jgarnett 3) RnD updates
jgarnett jdeolive? How goes the good fight?
jdeolive goes well, new expression / filter api is pretty much done awaiting qa
jdeolive starting to work on getting the new feature model in
jdeolive just looking at the geoapi interfaces
jgarnett what is needed for QA? And can we kick it out as a 2.3.M0 before the rest of the feature model lands?
jdeolive we could, i would have to merge what is on the fm branch onto trunk
jgarnett I would not mind doing that, problem is lack of a geoapi SNAPSHOT.
jgarnett any advantages for you justin? Early feedback and more eyes testing? vs time taken to make a release and merge to trunk?
jdeolive yeah i dont know, i think someone is going to have to volunteer to do this, i really have an abundance of time
jdeolive it does need the feedback though
jgarnett Volunteer to merge, or volunteer to release?
jgarnett I would like to volunteer for the merge, but I imagine you and I are busy on the feature model.
jdeolive release, i can do the merge
jdeolive if someone else could merge that would be ideal
jgarnett okay, anyone want to try some maven 2 wonderment? It would be good to have someone else beside martin press the buton?
clint__ Sure I will help with this one
clint__ what do I need to do?
jgarnett okay I got the permission to upload the stuff, we can do it tomorrow.
jgarnett (Or actually when justin has the merge?)
jgarnett would that work justin?
jdeolive ok, i was kind of waiting for you to qa it while on the branch
jdeolive be nice for at least someone else to do a build
jgarnett As for the feature model hacking: http://udig.refractions.net/confluence/display/HACK/Feature+Model+hacking+notes
jdeolive of the fm branch
jgarnett I have been building the fm branch justin.
jdeolive ok cool
jgarnett but I have not had a chance to qa it yet, was going to wait until I needed to write testcases for POJO / EMF featrure model bindings
jdeolive so yeah i had a few minor tasks to clean up and then i can merge onto trunk
jgarnett Cool, we will watch email.
jdeolive how are we going ot manage geoapi?
jdeolive SNAPSHOT?
jgarnett same way we did it before - DATESTAMP
jgarnett (SNAPSHOT was always evil and we spent half our time emailing Martin)
jdeolive ok
jgarnett Anybody have questions about RND land? Seems that the coverage branch is getting organized ... I hope we don't hold them up.
jgarnett iant_ are you PMC these days?
iant_ I think so
jgarnett (note: osgeo channel is trying to figure out what to make of geotools svn repository right now Good to know we are eagerly welcomed)
jgarnett I was going to volunteer you in the next agenda item (he he)
jgarnett 4) Martin wants a plan (or has a plan?)
iant_ ?
jgarnett I try and update the RND page to reflect what is going on (and when), do you think you can beat the answers out of the email list this time?
jgarnett Does the request make sense? Is there anything we don't know about?
iant_ I could try
jgarnett Jesse_eichar is uDig off the critical path for trunk now? Aka just working on 2.2.x until release day?
Jesse_eichar yes
jgarnett Well that is one down.
jgarnett jdeolive - do we have a timeline for the feature model work?
jdeolive 2-3 weeks
jdeolive end of feb
#geotools
jgarnett As for coverages I think we will need to check email? I don't see any of the usual suspects around...
acuster what are the docs that will be available explaining the work?
jgarnett confused, which work? Docs will be on the wiki - hanging off the RnD page.
jgarnett Anything else iant_ (thanks Ian) can hunt down via email.
jgarnett 5) benchmarks
jgarnett Over to you clint__
iant_ just to check which page should I be cheking
clint__ I ran a few test Hibernate vs EJB vs Features
jgarnett Good question iant_ RnD page is the best starting point, update the road map and throw up a news item if you want to be extra nice.
iant_ ok
clint__ Time to get back 13000 feature initially for EJB vs hibernate vs Features was 25secs vs 5secs vs 5.1secs respectively
jgarnett so we are a bit slower.
clint__ But once the container was loaded for the EJB stuff...
clint__ EJB was crusing in under a second to return the 13000 features
clint__ Feature was constant at 5.1sec hibernate came down to under 2 secs and EJB under 1 second
clint__ so in fact once the entity beans are loaded in the container there is simply just communication between beans and ..
clint__ application and the application server keeps the bean state consistent or updated
jgarnett Of course these were not with spatial queries, but we may yet teach hibernate something about that.
jgarnett And the cache used behind hibernate is available to us (Apache Software License)
clint__ No we have some problems with mapping spacial queries
jgarnett https://whirlycache.dev.java.net/
clint__ some interesting reading
jgarnett that is it for the meeting I guess - unless anyone wants to talk shop.
clint__ Nope not for now..
1. OSGEO
2. Filter / Expression API Transition
3. Quality Control
<iant_> I'd like to add open source geosatial foundation discussion
<jdeolive> 1. OSGF
<iant_> I think we're prefering OSGEO
<jdeolive> ooops, sorry
<jdeolive> 1. OSGEO
<jdeolive> 2. Expression / Filter API update
<jgarnett> Yo.
<iant_> hi
<jgarnett> (hey cool - cameron is going to crash our meeting)
<jdeolive> cool
<jgarnett> We are having a meeting right ...
<jdeolive> current agenda:
<jdeolive> 1. OSGEO
<jgarnett> ... you guys are all not waiting around or anything.
<jdeolive> 2. Expression / Filter API update
<jgarnett> sweetness x2
<jdeolive> we were wating a couple of more minutes for stragglers such as yourself
<jgarnett> I got a annoying thing on the user list, so I am going to put on ...
<jgarnett> 3. Quality Control
<iant_> I saw that too
<jgarnett> Hi hobu
<jgarnett> 0. Everyone welcome hobo
<jdeolive> welcome !!
<jgarnett> So um, hobo - I am a spatial hacker - this is the 12 step program
<jgarnett> who are you?
<hobu> you don't know who I am?
<iant_> foundation spy
<hobu> hah!
<jgarnett> (we are teasing you)
<jgarnett> As long as you are here you can review mhy blog post; I thought I should respond to the java representation thang;
<jgarnett> And you are warned that my writing involves a spelling based drinking game.
<hobu> trying to see how closely geotools discusses the foundation stuff in relation to the RFC I put togetther for mapserver http://mapserver.gis.umn.edu/development/rfc/ms-rfc-10/view
<jgarnett> http://weblogs.java.net/blog/jive/archive/2006/02/_open_source_ge.html
<jgarnett> sweet - well lets move into ageanda item 1 shall we?
<hobu> ie, how does a "coalition of the willing" mandate the movement to anything/anywhere?
<hobu> (US military reference just by coincidence
<jgarnett> easy, if you don't interoperate you look bad
<jgarnett> good old fashion compitition on speed, usability never hurt anybody. Compitition with gvSig has done wonders for our index shapefile support.
<jgarnett> Justin can you herd us along today? There is so much exciting stuff going on I need somebody to cut me off before we run out of time
<jdeolive> alrighty
<jdeolive> 1. OSGEO
<jdeolive> iant_, i beleive the floor is yours to start
<iant_> sorry was just reading Jody's ramblings
<iant_> As you are probably all aware I went to Chicargo on Sat and was involved in disscussing the beginings of the OSGEO foundation
<jgarnett> (ow that hurt, oh wait you have to read my source code as well)
<iant_> (as a side note I have no C key on this machine so they may be missing occasionally)
<iant_> The foundation ame out of some mad plan hatched by Autodesk and the mapserver folks.
<jgarnett> (as you can see hobo the java community is high tech, we are just moving away from punch cards, a few people are confused and pop out keys during the transition)
<iant_> Initially this was poorly received so a second plan was made
<iant_> thus more people were invited to attend including geotools
<iant_> hang on phone call
<jgarnett> I see - have you guys had a chance to read the various material, iant_ email and so on ?
<jgarnett> Does anyone have any questions so far?
<iant_> I'm back
<iant_> sorry about that
<iant_> There was lots of discussion! We chose a name the Open Source Geospatial Foundation (OSGEO)
<iant_> the basic outline of the foundation is based on the Apache model and we had Brian from Apache and Collabonet along to advise us
<iant_> currently everyone who attended the meeting in person are members of the foundation and we are looking for nominations for the next 20 members
<iant_> when this group is sorted we'll elect 4 more board memebers to add to the 5 elected yseterday (includes our own ChrisH/cholmes)
<iant_> The foundation is now looking for projects to support -
<iant_> this is where we come in
<iant_> while exactly what we'd get out of membership is not entirely clear yet, we would get hosting for wiki, mailing lists, svn etc
<iant_> we would also get geotools.osgeo.org as a domain name
<iant_> the idea would be for some sort of common look and feel between projects (like on the Apache site)
<jgarnett> I am more interested in an IP check, common branding, and visibility.
<iant_> but that each projet would keep its own pmc and management style
<iant_> we would need to carry out an IP check and assign a right to redistribute to the foundation but not the actual code
<jgarnett> (does not seem like a burden since we are LGPL?)
<jdeolive> coming up on meetin half time
<iant_> if we give the foundation joint ownership of the code they can help defend us on legal challenges
<iant_> OK we all need to think more on this - there is lots of stuff out there to read. If people are blogging or come across useful stuff can they mail the list
<iant_> I would like to see us join but I don't want anyone to feel pushed in before we know anything
<iant_> quick questions? or should we move on?
<iant_> anyone out there?
<jgarnett> hint: PSC is Project Steering Comitee - aka PMC
<jgarnett> (but apparently friendly)
<jgarnett> iant_ you were there, it was hard from IRC logs to tell what was going on all the time.
<iant_> indeed - it was hard to keep track while being there
<iant_> much is still to be decided by the interim board and members
<jgarnett> Did they decided to go big with respect an open source push, or did they leave that on the table?
<jgarnett> (aka delegate to the new board)
<iant_> the idea is to get a web site/wiki and mailing lists up soon
<iant_> a big open source push?
<CameronShorter> I'm ex-geotools developer, and now with Mapbuilder. We decided to join because we would like to see an Open Source GIS body which promotes integration and can present a united front to compete against the big proprietary products.
<Polio> So, I may have missed this part ... but I was wondering about the branding portion of the proposal
<Polio> I was hoping we could have a short round table on this
<iant_> there will be a brand and a logo which if geotools joined we'd be able to use
<iant_> I don't want to use the whole meeting for this - but I can hang on after for further discussion
<Polio> I was more concerned with the required portions, not the optional ones
<jgarnett> Good questions, I am not sure what the required portions would be. I imagine for legal purposes we would need an IP check.
<iant_> the requiement would be to make all of the different project websites look alike -
<iant_> in the same way that each apache site has the same look and feel
<Polio> Ok, given that requirement ... I'm tending between a 0 and -1 vote.
<iant_> you know where to go to find the download
<Polio> I'm VERY concerned about the branding ... ie being swallowed up
<iant_> If we're first in we get to describe the web site shape to an extent
<jgarnett> So far I have been the confluence dude, I can certaintly do the work if that is what people want.
<jgarnett> Polio are you worried about losing the geotools brand?
<iant_> We'd always be geotools - in time we'd become osgeo-geotools
<Polio> Um ... I'm more concerned with looking like a single dot in the field
<Polio> Yes Jody
<iant_> I'm not sure what you mean polio
<jgarnett> The flip side of this is a race, aka Deegree is looking to matter, and they could easily step in.
<iant_> this is more a case of an oppertunity to get our name more widely spread
<Polio> In trying get the right wording ...
<jgarnett> I understand what he is getting at iant_, the apache commons library is great, but it is not a strong brand on its own. I think apache is different because they started with one good application and bred others.
<iant_> especially with people who currently look to the C stack (i.e. mapserver)
<Polio> I'm worries we would be lost in the sea of projects ...
<CameronShorter> Polio, I think the Geotools footprint would increase by assotiation with the Foundation rather than be swallowed up. Visability of Geotools would increase with association.
<iant_> I guess there is a risk of that - at present there is always a risk people don't really know the difference between udig, geoserver and geotools
<jgarnett> osgeo has several really good brands going in, I trust our brand. What I don't want osgeo to get in the way of these projects competing.
<jgarnett> Which tends to be assumed when you watch the apache project turn.
<Polio> I'm not fairly sure you're right cameron ... but I wanted us to think about this
<jgarnett> when they bring out somethiing new in the same space, you assume it is to replace the last one.
<iant_> I think the GT brand is strong. There is no sign of another java mapping toolkit comming out of the foundation,
<Polio> Jody, hadn't though of it exactly like that (just the consequences)
<CameronShorter> Polio, you may also have similar concerns that we had regarding loosing control? We at Mapbuilder were satisfied that our PMC would retain control of our project.
<iant_> they are more concerned to have a java presence currently
<Polio> Cameron, from that angle I wasn't worried due to our current PMC model and licence
<Polio> I'm looking at this from a maketing perpective, and trying to see issues a few yearrs down the line
<jgarnett> I can think of several good candidates, Deegree is more consistent then us and has a more complete stack, gvSig looks generated and the docs are in spanish but their performance caused the indeced shapefile work.
<Polio> *marketing
<iant_> I think there is always a risk of a library project ending up with a lower profile than a sexy application
<jgarnett> I think Polio is concerned about losing eyeballs
<Polio> eyeballs?
<iant_> I think that is a greater risk if we miss this chance than if we take it.
<iant_> this is a chance to be on the same website as mapserver gdal ogr mapbuilder mapbender ossim etc
<Polio> Ok, well I have more to think about atleast (thanks for everyone putting up with the devils advocate here)
<iant_> cholmes thinks geoserver would probably follow gt in
<jgarnett> I agree iant_ but we should watch how things progress. My concern is that the foundation will be busy on infrastructure and not develope a strong marketting presense
<jgarnett> (although the budget thread does mention attending convernces and promotions as priorities)
<iant_> I think a 250k$ budget should lead to quite alot of marketing
<jgarnett> depends hardware, and bodies cost a bit. They mentioned a person on staff...
<iant_> since the foundation is buying in most of the infrastructure direct
<iant_> there is talk of building an SDI testbed
<iant_> which could get a lot of attention
<jgarnett> In anycase we should progress with the rest of our meeting, I have already cast my +1 vote. I would like to see everyone vote on this if we can manage it.
<iant_> If the foundation does appoint a director they would have to mostly market it
<iant_> I really want to hold off voting untill next week so we can have more discussion
<iant_> plus by then we should have a better idea of whats what
<Polio> Yah, a week to mull it over, ask question (and hopefully have a few lively debates) would be nice
<iant_> there is no rush
<jgarnett> hobo do you know of a timeline?
<jgarnett> aka 2 weeks was mentioned, if that to get in on the gound floor anouncement?
<jgarnett> Last time this was a problem, and I don't care much if geotools is in the first draft or gets its own press release later. But a question of timing is no doubt important for you and the MapServer lot.
<jgarnett> Okay, Ian you were there. Timeline?
<iant_> none yet
<jgarnett> If not I will assume the two weeks as mentioned in the IRC channels.
<iant_> everyone basically had to go back to thier projects and talk it over
<hobu> the "competition" issue is a contentious one for Mapserver as well (re: MapGuide).
<jgarnett> Understood, question for you
<jgarnett> does MapGuide do WFS-T ?
<hobu> mapguide doesn't do squat for OGC at this time
<jgarnett> Really? I wont ask you what it does then ...
<hobu> It renders pretty.
<jgarnett> It may be fun if they are the only player that does not talk to all the others. Do they have plans?
<jgarnett> well we can take this offline ... next agenda item please
<hobu> I think they will agressively particpate. Their software already takes in quite a bit of the "c" stack
<hobu> sorry
<jgarnett> no worries you type fast around here - or someone else speaks.
<jgarnett> 2. Expression / Filter API update
<jgarnett> jdeolive - how is it happening?
<jgarnett> Do you want me to do the geoapi update first?
<jdeolive> its going good
<Polio> I don't see martin here ... but I would like us to think about our involvement with geoapi ... and how we would be situated (ie, I didn't see them included in the proposed set of projects, and should this impact us if we joined).
<jdeolive> i sent some mail to geoapi-devel, if youcould answer that woudl be nice
<Polio> oh, sorry I'll go to email
<jgarnett> I could not build you branch - geoapi-2.1 was mentioned. Can we build based on datestamped snapshots please?
<jdeolive> sorry Polio, that was for jody
<jdeolive> your concern is defintley valid
<jgarnett> Polio - I asked about GeoAPI and was shot down
<Polio> That was why I though we might want to talk about it
<jgarnett> They kinda felt it was under OGC control, I did not have the heart to mention that James/Martin started it and I was willing to take it back
<Polio> do we need to worry about opposing presures as it were
<jdeolive> i uploaded the timestamped jar
<jgarnett> Well I said flat out that GeoAPI fit the osgeo interoptability mandate to a T, and I would like to see it included.
<jgarnett> I better email that list, see what happens. Would that help polio?
<Polio> Yes thankk you
<jgarnett> Polio the other pressure is that geoapi does not move, if this experiment of justins does not go ahead we will need to formally split ways with geoapi on the Feature/Geometry etc... issues.
<jgarnett> emailing now.
<iant_> I saw no problem with geoapi joining foundation but since they are more closly coupled with the OGC they might not need to join
<Polio> I was just concerned about being the implementation pawn between two interface projects in the future, and what that could do to the project
<Polio> Jody, I'm fine with that ... so long as we have a longterm plan
<jgarnett> I do, but it is not always politic so I have been keeping it to myself.
<Polio> But I should run, thanks all for the productive banter (feel much better about this proposal now)
<jgarnett> later, thanks Polio
")
<jgarnett> jdeolive - anything else.
<jgarnett> when do we start features?
<jdeolive> hopefully this week
<jgarnett> ack - okay I can code up the interfaces tomorrow night.
<jgarnett> (I thought I had till the weekend)
<jgarnett> can you move us to the last agenda item ....
<jdeolive> you probably do, i have some preparation to do for my trip so I am not really full time this week
<jgarnett> t 3. Quality Control
<jgarnett> iant_ what was your take on the user lists?
<jgarnett> Not sure everyone is signed up let me summarize:
<iant_> he seemed unhappy
<jgarnett> A group from itally tried usin geotools, in particular OracleDatastore. Patched it to death, got no support and went away.
<jgarnett> I am not impressed, indeed I am not impressed with a few of the datastores that have had blockers for a couple releases now.
<jgarnett> So how can we do better?
<iant_> there are some problems with oracle as it has no real maintainer
<jgarnett> I see so this is a toss it out of the build, or PMC hunt for someone to maintain it situtation?
<iant_> but he seemed unhappy with the whole datastore stack (especially jdbc*)
<jgarnett> I need it and I can fix it, but JDBCDataStores are a mess, as generations of developes on a quick project insert optimizations.
<jgarnett> His opionon is justified.
<iant_> unless we can find someone who actually uses oracle it is hard to look after
<jgarnett> Understood, my time would be better spent cleaning up JDBCDataStore so that maintaining the silly things is not so hard.
<jgarnett> If we can find a volunteer let me know, I would love to tag team the problem and get a solution that would last.
<jgarnett> But we still have a quality issue, we have metrics (60% test coverage) which so far only Justin has met.
<iant_> plus we tell people how to build with out running the tests
<iant_> I think the main trust was we should actually fix some bugs before we add more interfaces etc
<jgarnett> And we have been unable to follow our own code formatting. Yes we are not doing so good 
<jgarnett> That one cuts close to home, and I agree. But I cannot fix some of the problems the way things are laid out now.
<jgarnett> ( I am trying to work through the stack, we did filter, style, and we are on filters)
<jgarnett> data store will probably be next on my list ...
<iant_> I have more time now so I'll see what I can do as well
<jgarnett> that would be great, one of the best things we could do (as PMC even) is help the module maintainers get thier Jira lists under control. Jira is full to the point of being ignored...
<iant_> indeed
<jgarnett> Any ideas would be good, the other is not include modules in the release that are not ready (even if it means we take a capabailities cut publically)
<jgarnett> I don't mind open development, and if we drop some datastores due to lack of a module maintain I am okay with that.
<jgarnett> In uding we call these "unsupported" plug-ins...
<jgarnett> uding = udig (sigh - it is late sorry).
<iant_> I think that might be better than releasing with bad code
<jgarnett> We have done it before with our legacy module, and we can put a positive spin on it ( vounteer and make this a supported plugin).
<jgarnett> But please if anyone has any ideas we need help.
<jgarnett> (my other idea is kill the PMC and return to module maintainers - when keeping a module working is your reason to be here we may get better results)
<iant_> works for me - I get to go home
<jgarnett> Sorry for the doom and gloom guys, meeting attendence is up (and meetings are shorter), and our api is getting much better one layer at a time.
<iant_>
<jgarnett> heck we would make you module maintainer of main (that will keep him out of trouble)
<jgarnett> seriously iant_ cholmes is module maintainer of several orphaned modules - even just helping him with Jira would be great.
<iant_> I'll try to make a start on that
<iant_> now I've finished moving I have much more time
<jgarnett> Are we done?
<iant_> jody can you mail me those geoserver transaction docs?
<jdeolive> I think so
<jgarnett> confused iant_ what do you mean?
<jgarnett> as in how to do it? Geoserver is normal struts there is a scary file somewhere in there with all the names broken down...
<iant_> you said you had some review docs on transactions ( I think it was you)
<jgarnett> ah transaction (sorry very late)
<jgarnett> you know that blog entry - it is in there
<jgarnett> http://weblogs.java.net/blog/jive/archive/2006/01/geoserver_wfst.html
<jgarnett> I think you will be the second person to read it
<iant_> thanks
<jgarnett> you say that now
<jgarnett> please send questions to geoserver devel
<jgarnett> hobo - did you want to chat. Meeting seems over.
<jgarnett> How is the MapServer community doing, same concerns as here?
<jgarnett> Hey justin did you want that blog entry for your documentation
<jgarnett> jdeolve - replied to your geoapi email...