| | 43 | {{{ |
| | 44 | Start of #mapguide buffer: Thu Nov 05 13:21:30 2009 |
| | 45 | * Now talking in #mapguide |
| | 46 | * Topic is 'MapGuide Open Source | Home: http://mapguide.osgeo.org/ | Bugs: |
| | 47 | http://trac.osgeo.org/mapguide | See Also: #OSGeo #FDO | Stats: http://www.ohloh.net/proje |
| | 48 | cts/4656 -and- http://cia.navi.cx/stats/project/MapGuide' |
| | 49 | * Set by unknown on Thu May 29 12:24:17 |
| | 50 | * bdechant (n=chatzill@132.188.71.11) has joined #mapguide |
| | 51 | * rbray (n=rbray@132.188.71.9) has joined #mapguide |
| | 52 | <rbray> Hey all, just going to give folks another minute or two. Tom is whining about |
| | 53 | re-installing FireFox and now he does not have an IRC client |
| | 54 | <rbray> Anyone care to take minutes? |
| | 55 | <trevorw> I think I did last time, does that exclude me this time? |
| | 56 | <rbray> Not at all - regular suckers welcome |
| | 57 | <rbray> oh I mean volunteers |
| | 58 | <trevorw> Ok. Let me try something. I may be able to do it again. Haven't used the IRC |
| | 59 | client in a while. |
| | 60 | * tomf2 (n=chatzill@132.188.71.3) has joined #mapguide |
| | 61 | <rbray> Last I looked we only have one agenda item - 2.1 Release Update |
| | 62 | <trevorw> I should be able to take minutes. We might want to add RFC 86 Pinned Connection |
| | 63 | and TCP/IP forward compatibility to the agenda items. |
| | 64 | <trevorw> (oops. TCP/IP backward compat) |
| | 65 | <rbray> ok |
| | 66 | <trevorw> I can also give a one liner update on the Sponsorship RFC. |
| | 67 | <rbray> ok |
| | 68 | <rbray> Let's start with the release. |
| | 69 | <rbray> If I read through the lines of Crispin's e-mail he was asking us to release based |
| | 70 | on RC1. Any thoughts or opinions? |
| | 71 | <bdechant> We need to release - it is long overdue. |
| | 72 | <trevorw> I haven't heard of any show stoppers with RC1. Installer reboot is a bit |
| | 73 | annoying and there seem to be some issues with the GDAL provider and ECW. Is anyone |
| | 74 | else aware of anything? |
| | 75 | <HarisK> we are using 2.1 latest Jason builds in couple production sites |
| | 76 | <rbray> So does anyone think we should not release 2.1 now? |
| | 77 | <rbray> Silence speaks. So then I will offically motion to release 2.1. |
| | 78 | <tomf2> +1 |
| | 79 | <rbray> +1 from me (it's way overdue) |
| | 80 | <trevorw> +1 Trevor - we may need to rebrand the installer. I can check with Jason. |
| | 81 | <HarisK> +1 |
| | 82 | <bdechant> +1 |
| | 83 | <trevorw> Is Kenneth online? He shows up in my IRC list. |
| | 84 | <rbray> OK - Motion passed. |
| | 85 | <rbray> Trevor, any basic rebrand is fine. When do you think we can get a build? |
| | 86 | <trevorw> I'm not sure. Jason was handling the 2.1 release. I will ping him after the |
| | 87 | meeting. |
| | 88 | <trevorw> I will add it as an action item - rebrand and send out official release ASAP. |
| | 89 | <rbray> Cool thanks. |
| | 90 | <rbray> Want to give us your sponsorship update next? |
| | 91 | <trevorw> I have started working on open source builds of trunk. As expected, there is a |
| | 92 | bunch of installer fixup to do. Been a bit slow getting to it but will hopefully have |
| | 93 | more time next week. |
| | 94 | <trevorw> For a Sponsorship update, Bob has granted me access to the mapguide osgeo pages |
| | 95 | and I have ping Tyler and Frank on how to create the sponsorship button in PayPal. Both |
| | 96 | Tyler and Frank have been busy with quarterly financials so I am hoping to hear back |
| | 97 | from them soon. |
| | 98 | <trevorw> I could update the main website but it might be a little strange if the |
| | 99 | Sponsorship/Donations page mentions a donate button that is not present. |
| | 100 | <trevorw> So I was going to wait for the button before updating the website. |
| | 101 | <rbray> Yea ok, I'd wait on that too. |
| | 102 | <rbray> Keep us posted. |
| | 103 | <rbray> On to the Pinned Connection RFC |
| | 104 | <rbray> HEre is what I know... |
| | 105 | <rbray> We (Autodesk) are going to put that RFC on hold. |
| | 106 | <rbray> I personally did not like it. The team who requested it believes they have a |
| | 107 | workaround which they are investigating as we type. |
| | 108 | <tomf2> It looks most likely that we will retract it because we can get equivalent |
| | 109 | functionality from the short transaction API (RFC 78) |
| | 110 | <rbray> They actually planned to use it to hold connections for the lifetime of a session. |
| | 111 | Which is not something I really support having explicit support for in our API. |
| | 112 | <tomf2> ...but yes, still investigating |
| | 113 | <rbray> So after we know if the workaround will work, then we will update the RFC |
| | 114 | <rbray> It will either (A) be removed, or (B) be brought back in some form |
| | 115 | <rbray> depending on whether the workaround works out |
| | 116 | <rbray> Any questions or concerns with this? |
| | 117 | <HarisK> by session in RFC I always thaught HTTP session |
| | 118 | <HarisK> I think it is even worse to have it "pinned" as part of MG session |
| | 119 | <HarisK> that is at leats my first impression |
| | 120 | <rbray> Yea me too, that's why I got vocal about it. |
| | 121 | <rbray> So Tom - can you update the status of that RFC and somehow mark it as On Hold. |
| | 122 | <tomf2> And that's also the reason we don't want to make this an API that people would use |
| | 123 | indiscriminately |
| | 124 | <tomf2> It would need to be used carefully or scalability and session replication are out |
| | 125 | the door |
| | 126 | <tomf2> session replication === failover |
| | 127 | <rbray> Yep |
| | 128 | <HarisK> yes |
| | 129 | <tomf2> I will mark the RFC as "on hold" |
| | 130 | <HarisK> my big vote would be for no-session MG |
| | 131 | <trevorw> I agree with you Bob, gobbling up Fdo connections is a serious scalability issue |
| | 132 | but having an exposed connection object is more in line with other apis (java and .Net). |
| | 133 | Not sure if there is a way to force the connections back into the pool after a specific |
| | 134 | period of time. Session lifetime based connections are definitely dangerous. HTTP call |
| | 135 | lifetime would be better as Haris suggested. |
| | 136 | <tomf2> done (marking on hold) |
| | 137 | <rbray> Also - please erase the voting history. |
| | 138 | <rbray> No one who votted on it understood the underlying implications, which is really |
| | 139 | bad. |
| | 140 | <tomf2> Sure, there is none --- the previous vote wasn't completed |
| | 141 | <rbray> ok |
| | 142 | <rbray> There is also a bug related to that RFC, where if you are using a connection and |
| | 143 | issue another command using the same resource id you get another connection. |
| | 144 | <rbray> We want to fix that. I think it's in Bruce's queue of work. |
| | 145 | <tomf2> That will be fixed as a bug, don't need an RFC for that |
| | 146 | <bdechant> Yup I'm fixing that up now |
| | 147 | <HarisK> yes, that is someting to fix |
| | 148 | <rbray> Right, just a bug fix |
| | 149 | <bdechant> It is a bug fix if the provider supports PerCommandThreaded or Multithreaded |
| | 150 | only |
| | 151 | <HarisK> btw, Jason is home - sick |
| | 152 | <bdechant> All providers today or PerConnectionThreaded - except GDAL which is |
| | 153 | SingleThreaded |
| | 154 | <bdechant> *are |
| | 155 | <rbray> ok |
| | 156 | <HarisK> hm, there was bug in MG with updates and threading |
| | 157 | <HarisK> can't remeber more right now, but I do remeber I changed what King.Oracle suports |
| | 158 | because of this bug |
| | 159 | <bdechant> Can you send me an email with the details Haris? |
| | 160 | <HarisK> but that is another story i guess |
| | 161 | <HarisK> yes, I will |
| | 162 | <bdechant> Thanks |
| | 163 | <rbray> or a ticket number? |
| | 164 | <HarisK> hope to remember |
| | 165 | <HarisK> :( |
| | 166 | <bdechant> Yes a trac ticket # would be nice too :) |
| | 167 | <HarisK> agree :) |
| | 168 | <rbray> ok - if you think of it, send it to Bruce via the mail list. |
| | 169 | <rbray> Trevor - can you mark that as an action? |
| | 170 | <rbray> for Haris |
| | 171 | <trevorw> Yes I will |
| | 172 | <rbray> Next Item: Haris/Trevor, want to discuss TCP/IP backward compatibility |
| | 173 | <HarisK> yes, I am working on georest |
| | 174 | <HarisK> btw, it is here www.georest.org |
| | 175 | <HarisK> together with Jason |
| | 176 | <HarisK> and I was unplesanty surprise that I can't use one build for multiple MG versions |
| | 177 | <HarisK> it turned out that I would need one build for every version of MG |
| | 178 | <HarisK> because of incosistent serialization/deserialization |
| | 179 | <HarisK> not incosistent but different |
| | 180 | <trevorw> Georest uses the web extensions API directly, effectively a 2 tier app going |
| | 181 | against MapGuide Server? |
| | 182 | <HarisK> and strangly it is even worse |
| | 183 | <HarisK> platformbase of MG 2.1 OS will crash MG Ent 2010 server ( strangly ) |
| | 184 | <HarisK> yes |
| | 185 | <HarisK> georest is using mapguidecommon, platforbase foundation... |
| | 186 | <HarisK> to communicate with instance of MG |
| | 187 | <rbray> So you are building against the C++ API that underlies PHP, .NET, JAVA? |
| | 188 | <HarisK> sorry ? |
| | 189 | <HarisK> georest is c++ |
| | 190 | <HarisK> http server or isapi or cgi .. |
| | 191 | <HarisK> then using those MG common libraries (c++) to talk to MG |
| | 192 | <rbray> AH |
| | 193 | <HarisK> and it seems now I cant have one georest |
| | 194 | <rbray> But you are linking against a specific build of the C++ code, and of course that |
| | 195 | cannot speak to older versions of MG |
| | 196 | <HarisK> which could talk to different MG servers |
| | 197 | <trevorw> Bob, the problem would also occur with php, .net, java if a 2.0 web extensions |
| | 198 | tried to talk to a 2.1 server. |
| | 199 | <rbray> got it |
| | 200 | <HarisK> yes |
| | 201 | <rbray> yep |
| | 202 | <HarisK> I found most of isues are about serialization/de |
| | 203 | <trevorw> Or possibly even a 2.1 RTM web versus 2.1 SP1 server. |
| | 204 | <HarisK> in which case versioning of those could help |
| | 205 | <rbray> Depends |
| | 206 | <trevorw> Yes. Haris is correct. For this to work, the Server would have to support |
| | 207 | previous versions of the TCP/IP ops. |
| | 208 | <rbray> versioning means we can detect the issue. |
| | 209 | <rbray> Actually making it work means supporting multiple stream versions. |
| | 210 | <HarisK> yes, but mostly it would be about adding new objects or members to existing |
| | 211 | objects |
| | 212 | <trevorw> And also be smart enough to send previous version objects back to the client in |
| | 213 | the response stream. |
| | 214 | <HarisK> for example latest issue is that MG 2.1 beta doesn't serialize schema name with |
| | 215 | class definition |
| | 216 | <bdechant> Maintaining multiple stream versions is lots of work :) |
| | 217 | <HarisK> hile latest MG 2.1 has schema name |
| | 218 | <HarisK> why lot of work ? |
| | 219 | <trevorw> For the case Haris encountered, yes. It is basically an object versioning issue |
| | 220 | on MgClassDefinition. |
| | 221 | <bdechant> Lots of work because none of the infrastructure is there. Then once the |
| | 222 | infrastructure to handle multiple streams is in place you have to maintain all of the |
| | 223 | different stream versions. |
| | 224 | <trevorw> It is difficult because the Server needs multiple paths to decode version 2.0, |
| | 225 | 2.1, 2.x operations and also has to be smart enough to return the correct object |
| | 226 | signature in response to the operation version. |
| | 227 | <tomf2> It sounds like we should put the version in the streams, but we will not be |
| | 228 | updating the web tier or server (infrastructure) to be able to talk to different |
| | 229 | versions of each other. Right? |
| | 230 | <HarisK> in streams there are allready few stream versions which are unused right now |
| | 231 | <bdechant> It is not just a simple task of adding a "Version" piece to the existing |
| | 232 | serialization/deserialization code and then you are done |
| | 233 | <rbray> Well... |
| | 234 | <HarisK> things like new member would be very easy to support, right ? |
| | 235 | <rbray> We could do this in phases |
| | 236 | <rbray> Phase 1: Actually make use of stream version and return an error on mismatch |
| | 237 | <rbray> Phase 2: Implement logic to handle multiple |
| | 238 | <bdechant> I would like to add the "Version" to the streams now and then tackle the |
| | 239 | compatibility as a 2nd phase |
| | 240 | <bdechant> I see Bob is already typing this :) |
| | 241 | <rbray> At least with (1) the behavior would be predictable. |
| | 242 | <tomf2> Is there a need to implement phase 2 in MG? |
| | 243 | <rbray> For what Harris wants, yes. One georest impl - any MG |
| | 244 | <rbray> But Harris, could you get by with just (1) for now? |
| | 245 | <tomf2> Oh, right, he's using the API and not communicating directly with the server |
| | 246 | <rbray> right |
| | 247 | <rbray> as he should be |
| | 248 | <trevorw> Third party C++ processing tools could also make use of this. An older version |
| | 249 | of the processing tool would still work against new MapGuide Servers. |
| | 250 | <tomf2> yeah, that seems like a lot of work to maintain going forward. Aren't there any |
| | 251 | other possible solutions? |
| | 252 | <trevorw> Same would go for "old" versions of third party php,.net,java libraries. |
| | 253 | <Kenneth_> I agree with trevor that in the general case, the objects can change in a |
| | 254 | multitude of ways, and maintaining it is hard, but for the changes I have seen, there is |
| | 255 | usually an additional field that is added. This is the same as the item being added to |
| | 256 | the XSD, which easily supports multiple version. |
| | 257 | <Kenneth_> There may be other changes, that I am not aware of. |
| | 258 | <trevorw> I can certainly work with Bruce and others on an RFC to support TCP/IP backward |
| | 259 | compatibility. There would be a lot of design decisions to make. |
| | 260 | <Kenneth_> But I still belive that the integration is too tight, forcing too much logic in |
| | 261 | the classes that have multiple purposes |
| | 262 | <tomf2> Who would implement and fund the work? |
| | 263 | <Kenneth_> If there is an intermediate layer that parses a "binary JSON" into C++ classes |
| | 264 | (and back) it would be better |
| | 265 | <rbray> I'd vote for an initial RFC that focuses on using versions and supporting the |
| | 266 | basic use cases. |
| | 267 | <Kenneth_> The version logic could be handled in the parser layer |
| | 268 | <HarisK> I am not completly sure how important it is |
| | 269 | <trevorw> I am sure we can come up with a solution for this but it would be a lot of work |
| | 270 | to maintain and test. All contributors would have to agree to do it. It would be a |
| | 271 | fundamental part of the coding standards. |
| | 272 | <HarisK> but it looks bad that I can't put out one application which would work with both |
| | 273 | MG 2.1 and Ent 2010 |
| | 274 | <rbray> HarisK: Agreed |
| | 275 | <trevorw> That's the problem. Currently all developers are facing a recompile for each |
| | 276 | new version of MapGuide. |
| | 277 | <tomf2> Then just choose Ent 2010 :) |
| | 278 | <CIA-35> MapGuide: brucedechant * r4330 /trunk/MgDev/Server/src/Common/Manager/ |
| | 279 | (FdoConnectionManager.cpp FdoConnectionManager.h): |
| | 280 | <CIA-35> MapGuide: Fix for trac ticket 1140 - Add better support for PerCommandThreaded/Mu |
| | 281 | ltiThreaded FDO providers |
| | 282 | <CIA-35> MapGuide: http://trac.osgeo.org/mapguide/ticket/1140 |
| | 283 | <CIA-35> MapGuide: Notes: |
| | 284 | <CIA-35> MapGuide: - Added a check for PerCommandThreaded/MultiThreaded FDO provider |
| | 285 | capability |
| | 286 | <CIA-35> MapGuide: - Allow FDO connections to be reused if the underlying FDO provider |
| | 287 | supports PerCommandThreaded/MultiThreaded |
| | 288 | <rbray> Bruce - multi-taksing are we? |
| | 289 | <HarisK> :) customer choose |
| | 290 | <bdechant> Yes :) |
| | 291 | <Kenneth_> Harris, are you using PHP for development? .Net actually allows you to load |
| | 292 | multiple version of the same dll, so it would be theoretically possible, but annoying to |
| | 293 | actually do. |
| | 294 | <tomf2> Yes, I'm just kidding, but couldn't multiple versions be put out, that are |
| | 295 | compiled against a particular version then... |
| | 296 | <rbray> Tom - yes but that is painful. |
| | 297 | <HarisK> yes I did just that |
| | 298 | <HarisK> but had to dig in adsk sanbox |
| | 299 | <HarisK> to find correct version to use |
| | 300 | <rbray> And Haris would need to know our Enterprise revision numbers so he can build |
| | 301 | against the right version |
| | 302 | <tomf2> We only release once every 2 years :( |
| | 303 | <HarisK> and can hope it is right one |
| | 304 | <tomf2> ...so not so painful |
| | 305 | <HarisK> but then it doesnt work agains MG 2.0.2 or 2009 or ..:( |
| | 306 | <rbray> yea this is a problem, I am just not sure who is going to fund/do the work |
| | 307 | <trevorw> The problem is exacerbated by 3rd party vendors. If a City subcontracts some |
| | 308 | library work against MG 2.0 then they have to back to contractor for a library update |
| | 309 | when they move to 2.1. Make the move harder. |
| | 310 | <rbray> There are some good solutions, but its a fair bit of work |
| | 311 | <trevorw> Do we start with an RFC to figure out a plan of attack and then evaluate how |
| | 312 | painful it is going to be? |
| | 313 | <HarisK> yeah :), I will build many georest's |
| | 314 | <rbray> trevorw: Sure - at least then it's captured. |
| | 315 | <rbray> Tom and/or Bruce: CAn you take an action to put this on our internal backlog of |
| | 316 | work to be done. I am sure it wont make it into a PRD, but it does not hurt to have it |
| | 317 | on the list. |
| | 318 | <trevorw> Ok. Who wants to be on the TCP/IP compat action item? Trevor, Tom & Bruce? |
| | 319 | <tomf2> I'll mention it to product management |
| | 320 | <rbray> Don't forget Haris |
| | 321 | <rbray> tomf2: Thanks. |
| | 322 | <bdechant> Please include me Trevor |
| | 323 | <tomf2> trevorw: not me, sorry |
| | 324 | <rbray> We are a little over time. Any other issues? |
| | 325 | <rbray> Then I motion that we adjourn. |
| | 326 | <trevorw> Do we want an action item summary? |
| | 327 | <rbray> Yes please put it in the minutes and send an e-mail to internals. |
| | 328 | <HarisK> thank you all |
| | 329 | <trevorw> Ok. I will. Please let me know if I miss something. |
| | 330 | <rbray> and thanks for taking notes Trevor. |
| | 331 | <rbray> thanks all. |
| | 332 | <bdechant> bye everyone |
| | 333 | End of #mapguide buffer Thu Nov 05 13:21:30 2009 |
| | 334 | }}} |
