Project Steering Committee - Home

Meeting Info

The fourteenth meeting of the MapGuide PSC will take place Thursday November 1st at 17:00 UTC (1:00 PM ET / 11:00 AM MT / 10:00 AM PT).

Meeting Chair: Bob Bray

Universal Time: ​http://www.timeanddate.com/worldclock/fixedtime.html?month=11&day=1&year=2007&hour=11&min=0&sec=0&p1=55

Location: The meeting will be held on IRC at ​#mapguide

Agenda

• MapGuide Open Source 2.0 Beta/Release Plan
• Availability of MGOS 2.0 Beta Test Servers
• (Paul) Discussion about MapGuide Security Model and how it might be made more useful
• Updated Individual CLA and a new Corporate CLA
• Other Business?
• RESTful Next Steps?

Actions

Transcript

 <rbray> I am ready to start. First topic MG 2.0 plan.
 <jasonbirch> How are we affected by: http://fdo.osgeo.org/roadMap.html
 <rbray> However I am not sure Tom is here.
 <tomf1> I'm here, in another meeting as well though
 <jasonbirch> he's a race car, of course he's here :)
 <tomf1> We are using FDO 3.3
 <rbray> We can Beta when FDO Betas
 <tomf1> FDO 3.3 has already been posted (I posted the files) so we can release the MGOS 2.0 beta with that.
 <jasonbirch> How long do you think the beta cycle on 2.0 will be?
 <tomf1> I'm hoping to have the MGOS 2.0 beta installers and tar file posted tomorrow or early next week so that we can internally test them before announcing generally
 <jasonbirch> Will we want to release on FDO beta, and then point-release when FDO goes gold?
 <rbray> The Beta will need to go at least until Jan to sync with FDO
 <jasonbirch> It would be nice if FDO and MapGuide release cycles were offset...
 <jasonbirch> This ispainful.
 <rbray> You don't know the half of it :)
 <jasonbirch> then you're not being open enough :)
 <rbray> I am always just as open as  I can be :)
 <rbray> And usually just a little more :)
 <tomf1> So the plan is to release FDO in January.  I missed that
 <jasonbirch> Yes.
 <jasonbirch> Which I'm sure is pushing MapGuide a bit
 <rbray> So did I, but yes that is what Gregs roadmap shpws.
 <jasonbirch> At least compared to previous release cycles.
 <rbray> I am in no hurry to release 2.0. I'd like a stable release for users.
 <tomf1> WRT Jason's previous remark about releasing on a beta FDO. I would like to release MGOS 2.0 at the same time as FDO is released.
 <tomf1> So MGOS 2.0 will release in January at the earliest.
 <rbray> Yep
 <rbray> Anyone have an issue with that?
 <HarisK> How far Fusion is regarding MGOS 2.0 ? That will be biggest news ?
 <jasonbirch> No, as long as we get betas to play with in between.  No slacking off :D
 <tomf1> Betas should come every two (or three) weeks
 <rbray> Fusion and the completion of the stylization work. And maybe AGG are the big items.
 <tomf1> Fusion is looking good in MGOS 2.0
 <HarisK> great
 <jasonbirch> If we could get some windows build scripts into the repository that would be cool...
 <jasonbirch> I'd like to start playing with nullsoft so that we can have development builds.
 <jasonbirch> nsis I mean
 <rbray> So from a Planning perspective it looks like:
 <rbray> Beta 1: Soon
 <rbray> Beta 2: Third Week of Nov?
 <rbray> RC1: Early December
 <tomf1> I don't want to plan the subsequent demos
 <tomf1> I mean betas
 <rbray> RC2: Early Jan
 <rbray> OK, so more Betas.
 <rbray> How often?
 <jasonbirch> We could use that as a general plan and then vary based on bugs, etc?
 <pagameba> hello
 <pagameba> sorry I'm late
 <tomf1> The release candidates match with FDO though so that is good
 <rbray> Hey Paul
 <jasonbirch> Hi Paul
 <HarisK> Hi
 <tomf1> If beta 1 has many problems, we may have to do a beta 2 sooner.
 <jasonbirch> Hey, with this schedule...  when is Mentor going open? :)  (config-file option like AGG?)
 <tomf1> Never mind. I guess, we can plan for third week of november, but that can change.  OK, let's go with what you have
 <rbray> At this point Mentor will be MGOS 2.1
 <jasonbirch> I think we're good with this topic?
 <tomf1> Everyone ok with 2 betas and two rcs?
 <HarisK> +!
 <HarisK> +1
 <rbray> With a third beta if required I assume.
 <jasonbirch> +1 ... unless things really fall apart :)
 <pagameba> +1
 <tomf1> Yes, this would be the minimum.
 <rbray> OK lets push on.
 <rbray> What do people think of having a couple of MGOS 2.0 Hosted Test Servers?
 <pagameba> w00t!
 <rbray> Upload your data and app without having to install it?
 <jasonbirch> That would be cool.
 <jasonbirch> $2 per minute?
 <rbray> Free this time around
 <jasonbirch> Hosted on the amazon cloud servers? :)
 <rbray> Unfortunately no
 <jasonbirch> I like the idea Bob.
 <rbray> It was a suggestion Trevor made, and I think we can make it happen.
 <pagameba> off topic: I have an AWS account ... its pretty cool but too expensive on data transfer
 <pagameba> to be practical
 <pagameba> back on topic.
 <jasonbirch> I'd also like to see us put together a linux (ubuntu is nice) VM, and maybe look at EC2 at some point.
 <Andy_Morsell> I like the hosted idea as well.  But, it could get tough to manage and I would be leary of repository corruption problems affecting everyone.....
 <rbray> Yes I agree with that, but finding cycles is hard. We have a couple of Ubuntu users now maybe we can get some help
 <jasonbirch> For trials, etc it's great.
 <rbray> Right, this is just for Beta Testing.
 <jasonbirch> (hosted or EC2)
 <rbray> Not for hosting a real app.
 <Andy_Morsell> Alright then.  It would encourage more people to test, so that would be good.
 <pagameba> rbray, do folks have to buy Studio to work with the hosted servers?
 <pagameba> ;)
 <rbray> No.
 <tomf1> Is it that hard for people to install MGOS on their machines?
 <rbray> Web Studio will be installed.
 <jasonbirch> On Linux?  Yes.
 <tomf1> Why? because they have to be root?
 <rbray> tomfl: Problem is hardware, they cannot side-by-side install MGOS 1.2 and 2.0 Beta
 <jasonbirch> No, because they run into compile issues.
 <jasonbirch> Nobody actually runs centos or fc4 :)
 <tomf1> good point
 <pagameba> sadly we couldn't get an FGS build to be portable yet
 <jasonbirch> rbray: they can't?
 <rbray> I see the Beta hosting accomplishing two things:
 <rbray> 1. Get more testing of the beta, even if people just hit the test apps.
 <rbray> 2. We get access to the logs when things go south
 <rbray> and maybe 3. some random load testing
 <jasonbirch> Any chance you can build a "Bug" button into it, that takes the user's report, timestamps it (for comparison with logs) and ... wait for it ... opens a Trac ticket? ;)
 <tomf1> That sounds good to me
 <jasonbirch> How do you give the user their own "app"?
 <rbray> jasonbirch: Good idea, care to contribute that to the effort?
 <rbray> :)
 <jasonbirch> damn, I need to learn to keep quiet :)
 <jasonbirch> I'd actually consider it.
 <jasonbirch> Is there anything like WWW:Mechanize for PHP? :)
 <rbray> We'll see if we can get something up for internal testing (by this group) and go from there.
 <rbray> That sound ok?
 <tomf1> +1
 <jasonbirch> +1
 <HarisK> +1
 <pagameba> +1
 <Andy_Morsell> +1
 <rbray> Alright the next topic belongs to Paul.
 <pagameba> is that the security model dicussion?
 <rbray> Yep, unless you added something else to the agenda that I don't know about :)
 <pagameba> k
 <jasonbirch> http://trac.osgeo.org/mapguide/wiki/PscMeeting11-01-2007
 <jasonbirch> Welcome to mapguidetrac by the way...  patches?
 <pagameba> patches?
 <mapguidetrac> Patches graciously accepted :)
 <pagameba> 1. Security RFC: document the desired security model
 <pagameba> right now, the security model is very limited and I would argue broken
 <pagameba> for instance, opening a MapDefinition that includes a LayerDefinition that hte current user doesn't have access to
 <rbray> Cant be broken, it is not documented :)
 <pagameba> LOL
 <pagameba> also, it is programmatically very difficult to work with
 <pagameba> finally, it is not extensible
 <rbray> Wow, some people are picky.
 <pagameba> which means any real user-based system ends up storing user info outside and having to sync it
 <pagameba> or ignore MapGuide user system
 <pagameba> so ...
 <rbray> I agree with everything you state here. So...what do we do about it.
 <HarisK> I don't wan't to still your topic, but I think that also MG -> FDO user authentication is not adeqaute
 <pagameba> am I wrong on any of these?  and is there anything else that is wrong?
 <pagameba> good point Haris
 <rbray> Yep add the point Haris made.
 <pagameba> I don't know much about that part
 <pagameba> so ... solutions ...
 <pagameba> avoiding the first part for now
 <rbray> Ideally the MG and FDO security should be seamlessly integrated.
 <pagameba> I think we need a web tier API enhancement that allows testing the permissions of a user against a resource in some way
 <jasonbirch> And into external auth, like LDAP, OpenID, ActiveDirectory, etc.
 <pagameba> perhaps something like:
 <pagameba>     - $resourceService->testPermissions($myUser, 'read', $myResourceId)
 <pagameba> jasonbirch: yes, that was my next suggestion
 <rbray> That would not be hard.
 <pagameba>  new user authentication module plugin for LDAP
 <jasonbirch> And resources should be adaptive, if the current user does not have access to a component, swallow it gracefully and just don't display it.
 <rbray> From a big picture perspective I think we need to:
 <pagameba> not sure what needs to be done for MG/FDO
 <rbray> I think we need to document what we have, and document what we desire.
 <rbray> THen create a plan for going from A to B
 <jasonbirch> At least for layers in maps, and maps in applications.
 <jasonbirch> Users not having access to data in layers should probably throw an exception?
 <rbray> What about Fusion, app def, etc? Shoud commands drop out if the user does not have hte right to execute them?
 <jasonbirch> Absolutely.
 <jasonbirch> We may also need to have a way of overriding the permissions, so that if a layer is publishing data, it's OK, but the user can't access the data directly.
 <jasonbirch> proxying?
 <rbray> That is what I thought. Also pretty deep. Means we need a role based security model that propagates through the whole system.
 <pagameba> what we need is a user's perspective of how things *should* work
 <rbray> User or developer?
 <jasonbirch> pagameba: it depends on the implementation.
 <rbray> I would say an app developers POV
 <pagameba> um
 <jasonbirch> the application, I mean.
 <rbray> Yea how should an application behave.
 <jasonbirch> But in whatever case, it should not blow up.
 <pagameba> application developer I guess ... which would be a user from my point of view :)
 <jasonbirch> Andy_Morsell: you're keeping pretty quiet :)
 <HarisK> and we shouldn't ignore that for database extensive application's the users would come from database user's
 <jasonbirch> In an idea world, the database would be plugged into LDAP :)
 <jasonbirch> and use the same roles as the app...
 <HarisK> problem ritgh now is that FDO connections user is fixed when layer is created
 <HarisK> I suppose that means a big change for MG - FDO
 <jasonbirch> Yes, it would be nice to be able to pass authentication through to the data connection.
 <jasonbirch> It would mean excluding those connections from the pool?
 <pagameba> so we need some users of mapguide to document how they think various scenarios to work and developers of mapguide to document how it actually works ...
 <rbray> You can do that today.
 <rbray> Pass through the MG credentials to FDO
 <jasonbirch> rbray: is that documented?
 <rbray> Dunno
 <HarisK> I saw that once in a email
 <HarisK> but never saw that in a code
 <rbray> I probably wrote it.
 <HarisK> not in MGOS
 <rbray> I'll get Bruce to post something on that and how to use it.
 <HarisK> and once in a cache
 <rbray> Maybe it is broken, but I don't think so.
 <jasonbirch> Is that only if you're creating feature sources on the fly?
 <rbray> No
 <jasonbirch> Or is there a variable you can plug into the definition?
 <Andy_Morsell> Jason: sorry, in and out of the office.  Our solution for a recent project was to write an external database driven security application.  But, that doesn't prevent "backdoor" access to the resources if the user (programmer) knew what they were doing.
 <HarisK> it get used no metter of user
 <rbray> BAck to Pauls point please.
 <rbray> Haris, let's get Bruce to post how it shoudl work, then we can treat that like if defect if it is broken
 <HarisK> ok
 <rbray> I'll have him post that to internals
 <jasonbirch> Paul, can you put up some kind of straw horse on Futures?
 <jasonbirch> Then we can talk about it on -users...
 <rbray> I can probably get some input on Security requirements from our side. Be nice to have an external viewpoint as well though.
 <jasonbirch> Sure to get lots of feedback there...
 <rbray> Yep
 <pagameba> straw horse on Futures?
 <pagameba> ???
 <jasonbirch> http://trac.osgeo.org/mapguide/wiki/Future
 <jasonbirch> `Future
 <mapguidetrac> http://trac.osgeo.org/mapguide/wiki/Future
 <jasonbirch> hehehe
 <pagameba> ah
 <pagameba> ok
 <pagameba> yes
 <rbray> That will give us a place to collaborate.
 <jasonbirch> I unfortunately have to leave on time today... :)
 <HarisK> I could be repeating myself but I think that it is important to make changes together with FDO.
 <rbray> So do I so no worries.
 <HarisK> like support for proxy user
 <rbray> HarisK: I agree. Let's understand the requirements from an MG perspective, then feed them to FDO.
 <HarisK> ok :)
 <rbray> Ok, so Paul your action is to start a page on Futures. Then we'll start some collaboration around taht,
 <jasonbirch> CLAs?
 <rbray> Ready for the next topic?
 <HarisK> +1
 <pagameba> +1
 <jasonbirch> Do you have them posted Bob?
 <rbray> It is everyones favorite, contributor agreements.
 <rbray> The proposed CLAs are currently posted on the FDO site. They will be (hopefully) the same.
 <jasonbirch> What are the changes?
 <rbray> So far very little feedback from the FDO PSC.
 <rbray> The changes are: They are PRoject Specific, e.g specifically states MapGuide or FDO>
 <rbray> 2. There is a Corporate version that allows a corporation to name a list of developers.
 <jasonbirch> The CCLA looked OK, but I think that we need individuals as well, or an obligation to notify  _the project_ (not just OSGeo)when an individual is no longer covered.
 <rbray> I agree. That is the Apache Model.
 <jasonbirch> Can you send out the links by email, and we can vote to adopt there?
 <jasonbirch> (or maybe even discuss first) ;)
 <rbray> Yes I'll post the MG versions and send an e-mail for comments/feedback.
 <rbray> I'd like to motion to vote in a week or so.
 <rbray> What do we do about current CLAs?
 <rbray> I vote they stand as is, e.g. no need to resubmit.
 <tomf1> +1
 <jasonbirch> Is it important thatthe original submitters are not contributing to MapGuide or FDO?
 <jasonbirch> In other words, is it likely that FDO and MapGuide would continue if OSGeo went away?
 <rbray> ???
 <jasonbirch> I guess technically, the MapGuide and FDO projects are OSGeo legal entities anyway :)
 <rbray> THe projects would continue.
 <rbray> The umbrella would just need to be re-labled.
 <jasonbirch> So, granting a license to the project, rather than osgeo, is important?
 <rbray> Yes
 <jasonbirch> If so, then should be resubmitted.
 <rbray> Also the old ones gave rights across all projects, which is wrong.
 <jasonbirch> Ick, yes.
 <rbray> OR appear to anyway.
 <jasonbirch> I have to go.  Thanks all.
 <rbray> OK.
 <rbray> Lets pick this up next time. I also have to sign off ASAP.
 <tomf1> Ok
 <rbray> Thanks everyone. I will schedule another soon, maybe in two weeks once the beta is out.