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