| | 26 | |
| | 27 | {{{ |
| | 28 | <rbray> I am ready to start. First topic MG 2.0 plan. |
| | 29 | <jasonbirch> How are we affected by: http://fdo.osgeo.org/roadMap.html |
| | 30 | <rbray> However I am not sure Tom is here. |
| | 31 | <tomf1> I'm here, in another meeting as well though |
| | 32 | <jasonbirch> he's a race car, of course he's here :) |
| | 33 | <tomf1> We are using FDO 3.3 |
| | 34 | <rbray> We can Beta when FDO Betas |
| | 35 | <tomf1> FDO 3.3 has already been posted (I posted the files) so we can release the MGOS 2.0 beta with that. |
| | 36 | <jasonbirch> How long do you think the beta cycle on 2.0 will be? |
| | 37 | <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 |
| | 38 | <jasonbirch> Will we want to release on FDO beta, and then point-release when FDO goes gold? |
| | 39 | <rbray> The Beta will need to go at least until Jan to sync with FDO |
| | 40 | <jasonbirch> It would be nice if FDO and MapGuide release cycles were offset... |
| | 41 | <jasonbirch> This ispainful. |
| | 42 | <rbray> You don't know the half of it :) |
| | 43 | <jasonbirch> then you're not being open enough :) |
| | 44 | <rbray> I am always just as open as I can be :) |
| | 45 | <rbray> And usually just a little more :) |
| | 46 | <tomf1> So the plan is to release FDO in January. I missed that |
| | 47 | <jasonbirch> Yes. |
| | 48 | <jasonbirch> Which I'm sure is pushing MapGuide a bit |
| | 49 | <rbray> So did I, but yes that is what Gregs roadmap shpws. |
| | 50 | <jasonbirch> At least compared to previous release cycles. |
| | 51 | <rbray> I am in no hurry to release 2.0. I'd like a stable release for users. |
| | 52 | <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. |
| | 53 | <tomf1> So MGOS 2.0 will release in January at the earliest. |
| | 54 | <rbray> Yep |
| | 55 | <rbray> Anyone have an issue with that? |
| | 56 | <HarisK> How far Fusion is regarding MGOS 2.0 ? That will be biggest news ? |
| | 57 | <jasonbirch> No, as long as we get betas to play with in between. No slacking off :D |
| | 58 | <tomf1> Betas should come every two (or three) weeks |
| | 59 | <rbray> Fusion and the completion of the stylization work. And maybe AGG are the big items. |
| | 60 | <tomf1> Fusion is looking good in MGOS 2.0 |
| | 61 | <HarisK> great |
| | 62 | <jasonbirch> If we could get some windows build scripts into the repository that would be cool... |
| | 63 | <jasonbirch> I'd like to start playing with nullsoft so that we can have development builds. |
| | 64 | <jasonbirch> nsis I mean |
| | 65 | <rbray> So from a Planning perspective it looks like: |
| | 66 | <rbray> Beta 1: Soon |
| | 67 | <rbray> Beta 2: Third Week of Nov? |
| | 68 | <rbray> RC1: Early December |
| | 69 | <tomf1> I don't want to plan the subsequent demos |
| | 70 | <tomf1> I mean betas |
| | 71 | <rbray> RC2: Early Jan |
| | 72 | <rbray> OK, so more Betas. |
| | 73 | <rbray> How often? |
| | 74 | <jasonbirch> We could use that as a general plan and then vary based on bugs, etc? |
| | 75 | <pagameba> hello |
| | 76 | <pagameba> sorry I'm late |
| | 77 | <tomf1> The release candidates match with FDO though so that is good |
| | 78 | <rbray> Hey Paul |
| | 79 | <jasonbirch> Hi Paul |
| | 80 | <HarisK> Hi |
| | 81 | <tomf1> If beta 1 has many problems, we may have to do a beta 2 sooner. |
| | 82 | <jasonbirch> Hey, with this schedule... when is Mentor going open? :) (config-file option like AGG?) |
| | 83 | <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 |
| | 84 | <rbray> At this point Mentor will be MGOS 2.1 |
| | 85 | <jasonbirch> I think we're good with this topic? |
| | 86 | <tomf1> Everyone ok with 2 betas and two rcs? |
| | 87 | <HarisK> +! |
| | 88 | <HarisK> +1 |
| | 89 | <rbray> With a third beta if required I assume. |
| | 90 | <jasonbirch> +1 ... unless things really fall apart :) |
| | 91 | <pagameba> +1 |
| | 92 | <tomf1> Yes, this would be the minimum. |
| | 93 | <rbray> OK lets push on. |
| | 94 | <rbray> What do people think of having a couple of MGOS 2.0 Hosted Test Servers? |
| | 95 | <pagameba> w00t! |
| | 96 | <rbray> Upload your data and app without having to install it? |
| | 97 | <jasonbirch> That would be cool. |
| | 98 | <jasonbirch> $2 per minute? |
| | 99 | <rbray> Free this time around |
| | 100 | <jasonbirch> Hosted on the amazon cloud servers? :) |
| | 101 | <rbray> Unfortunately no |
| | 102 | <jasonbirch> I like the idea Bob. |
| | 103 | <rbray> It was a suggestion Trevor made, and I think we can make it happen. |
| | 104 | <pagameba> off topic: I have an AWS account ... its pretty cool but too expensive on data transfer |
| | 105 | <pagameba> to be practical |
| | 106 | <pagameba> back on topic. |
| | 107 | <jasonbirch> I'd also like to see us put together a linux (ubuntu is nice) VM, and maybe look at EC2 at some point. |
| | 108 | <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..... |
| | 109 | <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 |
| | 110 | <jasonbirch> For trials, etc it's great. |
| | 111 | <rbray> Right, this is just for Beta Testing. |
| | 112 | <jasonbirch> (hosted or EC2) |
| | 113 | <rbray> Not for hosting a real app. |
| | 114 | <Andy_Morsell> Alright then. It would encourage more people to test, so that would be good. |
| | 115 | <pagameba> rbray, do folks have to buy Studio to work with the hosted servers? |
| | 116 | <pagameba> ;) |
| | 117 | <rbray> No. |
| | 118 | <tomf1> Is it that hard for people to install MGOS on their machines? |
| | 119 | <rbray> Web Studio will be installed. |
| | 120 | <jasonbirch> On Linux? Yes. |
| | 121 | <tomf1> Why? because they have to be root? |
| | 122 | <rbray> tomfl: Problem is hardware, they cannot side-by-side install MGOS 1.2 and 2.0 Beta |
| | 123 | <jasonbirch> No, because they run into compile issues. |
| | 124 | <jasonbirch> Nobody actually runs centos or fc4 :) |
| | 125 | <tomf1> good point |
| | 126 | <pagameba> sadly we couldn't get an FGS build to be portable yet |
| | 127 | <jasonbirch> rbray: they can't? |
| | 128 | <rbray> I see the Beta hosting accomplishing two things: |
| | 129 | <rbray> 1. Get more testing of the beta, even if people just hit the test apps. |
| | 130 | <rbray> 2. We get access to the logs when things go south |
| | 131 | <rbray> and maybe 3. some random load testing |
| | 132 | <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? ;) |
| | 133 | <tomf1> That sounds good to me |
| | 134 | <jasonbirch> How do you give the user their own "app"? |
| | 135 | <rbray> jasonbirch: Good idea, care to contribute that to the effort? |
| | 136 | <rbray> :) |
| | 137 | <jasonbirch> damn, I need to learn to keep quiet :) |
| | 138 | <jasonbirch> I'd actually consider it. |
| | 139 | <jasonbirch> Is there anything like WWW:Mechanize for PHP? :) |
| | 140 | <rbray> We'll see if we can get something up for internal testing (by this group) and go from there. |
| | 141 | <rbray> That sound ok? |
| | 142 | <tomf1> +1 |
| | 143 | <jasonbirch> +1 |
| | 144 | <HarisK> +1 |
| | 145 | <pagameba> +1 |
| | 146 | <Andy_Morsell> +1 |
| | 147 | <rbray> Alright the next topic belongs to Paul. |
| | 148 | <pagameba> is that the security model dicussion? |
| | 149 | <rbray> Yep, unless you added something else to the agenda that I don't know about :) |
| | 150 | <pagameba> k |
| | 151 | <jasonbirch> http://trac.osgeo.org/mapguide/wiki/PscMeeting11-01-2007 |
| | 152 | <jasonbirch> Welcome to mapguidetrac by the way... patches? |
| | 153 | <pagameba> patches? |
| | 154 | <mapguidetrac> Patches graciously accepted :) |
| | 155 | <pagameba> 1. Security RFC: document the desired security model |
| | 156 | <pagameba> right now, the security model is very limited and I would argue broken |
| | 157 | <pagameba> for instance, opening a MapDefinition that includes a LayerDefinition that hte current user doesn't have access to |
| | 158 | <rbray> Cant be broken, it is not documented :) |
| | 159 | <pagameba> LOL |
| | 160 | <pagameba> also, it is programmatically very difficult to work with |
| | 161 | <pagameba> finally, it is not extensible |
| | 162 | <rbray> Wow, some people are picky. |
| | 163 | <pagameba> which means any real user-based system ends up storing user info outside and having to sync it |
| | 164 | <pagameba> or ignore MapGuide user system |
| | 165 | <pagameba> so ... |
| | 166 | <rbray> I agree with everything you state here. So...what do we do about it. |
| | 167 | <HarisK> I don't wan't to still your topic, but I think that also MG -> FDO user authentication is not adeqaute |
| | 168 | <pagameba> am I wrong on any of these? and is there anything else that is wrong? |
| | 169 | <pagameba> good point Haris |
| | 170 | <rbray> Yep add the point Haris made. |
| | 171 | <pagameba> I don't know much about that part |
| | 172 | <pagameba> so ... solutions ... |
| | 173 | <pagameba> avoiding the first part for now |
| | 174 | <rbray> Ideally the MG and FDO security should be seamlessly integrated. |
| | 175 | <pagameba> I think we need a web tier API enhancement that allows testing the permissions of a user against a resource in some way |
| | 176 | <jasonbirch> And into external auth, like LDAP, OpenID, ActiveDirectory, etc. |
| | 177 | <pagameba> perhaps something like: |
| | 178 | <pagameba> - $resourceService->testPermissions($myUser, 'read', $myResourceId) |
| | 179 | <pagameba> jasonbirch: yes, that was my next suggestion |
| | 180 | <rbray> That would not be hard. |
| | 181 | <pagameba> new user authentication module plugin for LDAP |
| | 182 | <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. |
| | 183 | <rbray> From a big picture perspective I think we need to: |
| | 184 | <pagameba> not sure what needs to be done for MG/FDO |
| | 185 | <rbray> I think we need to document what we have, and document what we desire. |
| | 186 | <rbray> THen create a plan for going from A to B |
| | 187 | <jasonbirch> At least for layers in maps, and maps in applications. |
| | 188 | <jasonbirch> Users not having access to data in layers should probably throw an exception? |
| | 189 | <rbray> What about Fusion, app def, etc? Shoud commands drop out if the user does not have hte right to execute them? |
| | 190 | <jasonbirch> Absolutely. |
| | 191 | <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. |
| | 192 | <jasonbirch> proxying? |
| | 193 | <rbray> That is what I thought. Also pretty deep. Means we need a role based security model that propagates through the whole system. |
| | 194 | <pagameba> what we need is a user's perspective of how things *should* work |
| | 195 | <rbray> User or developer? |
| | 196 | <jasonbirch> pagameba: it depends on the implementation. |
| | 197 | <rbray> I would say an app developers POV |
| | 198 | <pagameba> um |
| | 199 | <jasonbirch> the application, I mean. |
| | 200 | <rbray> Yea how should an application behave. |
| | 201 | <jasonbirch> But in whatever case, it should not blow up. |
| | 202 | <pagameba> application developer I guess ... which would be a user from my point of view :) |
| | 203 | <jasonbirch> Andy_Morsell: you're keeping pretty quiet :) |
| | 204 | <HarisK> and we shouldn't ignore that for database extensive application's the users would come from database user's |
| | 205 | <jasonbirch> In an idea world, the database would be plugged into LDAP :) |
| | 206 | <jasonbirch> and use the same roles as the app... |
| | 207 | <HarisK> problem ritgh now is that FDO connections user is fixed when layer is created |
| | 208 | <HarisK> I suppose that means a big change for MG - FDO |
| | 209 | <jasonbirch> Yes, it would be nice to be able to pass authentication through to the data connection. |
| | 210 | <jasonbirch> It would mean excluding those connections from the pool? |
| | 211 | <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 ... |
| | 212 | <rbray> You can do that today. |
| | 213 | <rbray> Pass through the MG credentials to FDO |
| | 214 | <jasonbirch> rbray: is that documented? |
| | 215 | <rbray> Dunno |
| | 216 | <HarisK> I saw that once in a email |
| | 217 | <HarisK> but never saw that in a code |
| | 218 | <rbray> I probably wrote it. |
| | 219 | <HarisK> not in MGOS |
| | 220 | <rbray> I'll get Bruce to post something on that and how to use it. |
| | 221 | <HarisK> and once in a cache |
| | 222 | <rbray> Maybe it is broken, but I don't think so. |
| | 223 | <jasonbirch> Is that only if you're creating feature sources on the fly? |
| | 224 | <rbray> No |
| | 225 | <jasonbirch> Or is there a variable you can plug into the definition? |
| | 226 | <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. |
| | 227 | <HarisK> it get used no metter of user |
| | 228 | <rbray> BAck to Pauls point please. |
| | 229 | <rbray> Haris, let's get Bruce to post how it shoudl work, then we can treat that like if defect if it is broken |
| | 230 | <HarisK> ok |
| | 231 | <rbray> I'll have him post that to internals |
| | 232 | <jasonbirch> Paul, can you put up some kind of straw horse on Futures? |
| | 233 | <jasonbirch> Then we can talk about it on -users... |
| | 234 | <rbray> I can probably get some input on Security requirements from our side. Be nice to have an external viewpoint as well though. |
| | 235 | <jasonbirch> Sure to get lots of feedback there... |
| | 236 | <rbray> Yep |
| | 237 | <pagameba> straw horse on Futures? |
| | 238 | <pagameba> ??? |
| | 239 | <jasonbirch> http://trac.osgeo.org/mapguide/wiki/Future |
| | 240 | <jasonbirch> `Future |
| | 241 | <mapguidetrac> http://trac.osgeo.org/mapguide/wiki/Future |
| | 242 | <jasonbirch> hehehe |
| | 243 | <pagameba> ah |
| | 244 | <pagameba> ok |
| | 245 | <pagameba> yes |
| | 246 | <rbray> That will give us a place to collaborate. |
| | 247 | <jasonbirch> I unfortunately have to leave on time today... :) |
| | 248 | <HarisK> I could be repeating myself but I think that it is important to make changes together with FDO. |
| | 249 | <rbray> So do I so no worries. |
| | 250 | <HarisK> like support for proxy user |
| | 251 | <rbray> HarisK: I agree. Let's understand the requirements from an MG perspective, then feed them to FDO. |
| | 252 | <HarisK> ok :) |
| | 253 | <rbray> Ok, so Paul your action is to start a page on Futures. Then we'll start some collaboration around taht, |
| | 254 | <jasonbirch> CLAs? |
| | 255 | <rbray> Ready for the next topic? |
| | 256 | <HarisK> +1 |
| | 257 | <pagameba> +1 |
| | 258 | <jasonbirch> Do you have them posted Bob? |
| | 259 | <rbray> It is everyones favorite, contributor agreements. |
| | 260 | <rbray> The proposed CLAs are currently posted on the FDO site. They will be (hopefully) the same. |
| | 261 | <jasonbirch> What are the changes? |
| | 262 | <rbray> So far very little feedback from the FDO PSC. |
| | 263 | <rbray> The changes are: They are PRoject Specific, e.g specifically states MapGuide or FDO> |
| | 264 | <rbray> 2. There is a Corporate version that allows a corporation to name a list of developers. |
| | 265 | <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. |
| | 266 | <rbray> I agree. That is the Apache Model. |
| | 267 | <jasonbirch> Can you send out the links by email, and we can vote to adopt there? |
| | 268 | <jasonbirch> (or maybe even discuss first) ;) |
| | 269 | <rbray> Yes I'll post the MG versions and send an e-mail for comments/feedback. |
| | 270 | <rbray> I'd like to motion to vote in a week or so. |
| | 271 | <rbray> What do we do about current CLAs? |
| | 272 | <rbray> I vote they stand as is, e.g. no need to resubmit. |
| | 273 | <tomf1> +1 |
| | 274 | <jasonbirch> Is it important thatthe original submitters are not contributing to MapGuide or FDO? |
| | 275 | <jasonbirch> In other words, is it likely that FDO and MapGuide would continue if OSGeo went away? |
| | 276 | <rbray> ??? |
| | 277 | <jasonbirch> I guess technically, the MapGuide and FDO projects are OSGeo legal entities anyway :) |
| | 278 | <rbray> THe projects would continue. |
| | 279 | <rbray> The umbrella would just need to be re-labled. |
| | 280 | <jasonbirch> So, granting a license to the project, rather than osgeo, is important? |
| | 281 | <rbray> Yes |
| | 282 | <jasonbirch> If so, then should be resubmitted. |
| | 283 | <rbray> Also the old ones gave rights across all projects, which is wrong. |
| | 284 | <jasonbirch> Ick, yes. |
| | 285 | <rbray> OR appear to anyway. |
| | 286 | <jasonbirch> I have to go. Thanks all. |
| | 287 | <rbray> OK. |
| | 288 | <rbray> Lets pick this up next time. I also have to sign off ASAP. |
| | 289 | <tomf1> Ok |
| | 290 | <rbray> Thanks everyone. I will schedule another soon, maybe in two weeks once the beta is out. |
| | 291 | }}} |
