[wiki:ProjectSteeringCommittee Project Steering Committee - Home] == Meeting Info == This meeting of the !MapGuide PSC took place Thursday, November 5, 2009 at 18:00 UTC (2:00 PM ET / noon MT / 11:00 AM PT). Meeting Chair: Bob Universal Time: http://www.timeanddate.com/worldclock/fixedtime.html?month=11&day=5&year=2009&hour=12&min=0&sec=0&p1=55 Location: The meeting will be held on IRC at [irc://irc.freenode.net/mapguide #mapguide] == Agenda == * Appoint a Meeting Secretary * The 2.1 Release * Sponsorship * RFC 86 Pinned Connection * TCP/IP Backward Compatibility == Minutes == PSC Members present: Bob, Bruce, Tom, Haris, Kenneth, Trevor === The 2.1 Release === * The RC1 build is stable with a few minor issues. * Jason will rebrand the RC1 build as the official !MapGuide 2.1 release and post for the community. === Sponsorship === * Trevor will create a Sponsorship page off the main !MapGuide OSGeo website once the donation button is ready. === RFC 86 Pinned Connection === * Autodesk is investigating a workaround for this RFC. * The RFC will be either updated or retracted based on Autodesk's investigation. * Tom will mark the RFC on hold pending the investigation. * Haris will forward Bruce details on an Feature Service updates/threading bug he discovered while working on the King.Oracle provider. === TCP/IP Backward Compatibility === * There are specific use cases where TCP/IP backward compatibility is useful. However, implementing backward compatibility will require significant effort. * Haris, Bruce, and Trevor will collaborate on an RFC to determine an appropriate implementation for this feature. * Further discussion will be undertaken by the PSC once the scope is better understood. === End of meeting === == Full transcript == {{{ Start of #mapguide buffer: Thu Nov 05 13:21:30 2009 * Now talking in #mapguide * Topic is 'MapGuide Open Source | Home: http://mapguide.osgeo.org/ | Bugs: http://trac.osgeo.org/mapguide | See Also: #OSGeo #FDO | Stats: http://www.ohloh.net/proje cts/4656 -and- http://cia.navi.cx/stats/project/MapGuide' * Set by unknown on Thu May 29 12:24:17 * bdechant (n=chatzill@132.188.71.11) has joined #mapguide * rbray (n=rbray@132.188.71.9) has joined #mapguide Hey all, just going to give folks another minute or two. Tom is whining about re-installing FireFox and now he does not have an IRC client Anyone care to take minutes? I think I did last time, does that exclude me this time? Not at all - regular suckers welcome oh I mean volunteers Ok. Let me try something. I may be able to do it again. Haven't used the IRC client in a while. * tomf2 (n=chatzill@132.188.71.3) has joined #mapguide Last I looked we only have one agenda item - 2.1 Release Update I should be able to take minutes. We might want to add RFC 86 Pinned Connection and TCP/IP forward compatibility to the agenda items. (oops. TCP/IP backward compat) ok I can also give a one liner update on the Sponsorship RFC. ok Let's start with the release. If I read through the lines of Crispin's e-mail he was asking us to release based on RC1. Any thoughts or opinions? We need to release - it is long overdue. I haven't heard of any show stoppers with RC1. Installer reboot is a bit annoying and there seem to be some issues with the GDAL provider and ECW. Is anyone else aware of anything? we are using 2.1 latest Jason builds in couple production sites So does anyone think we should not release 2.1 now? Silence speaks. So then I will offically motion to release 2.1. +1 +1 from me (it's way overdue) +1 Trevor - we may need to rebrand the installer. I can check with Jason. +1 +1 Is Kenneth online? He shows up in my IRC list. OK - Motion passed. Trevor, any basic rebrand is fine. When do you think we can get a build? I'm not sure. Jason was handling the 2.1 release. I will ping him after the meeting. I will add it as an action item - rebrand and send out official release ASAP. Cool thanks. Want to give us your sponsorship update next? I have started working on open source builds of trunk. As expected, there is a bunch of installer fixup to do. Been a bit slow getting to it but will hopefully have more time next week. For a Sponsorship update, Bob has granted me access to the mapguide osgeo pages and I have ping Tyler and Frank on how to create the sponsorship button in PayPal. Both Tyler and Frank have been busy with quarterly financials so I am hoping to hear back from them soon. I could update the main website but it might be a little strange if the Sponsorship/Donations page mentions a donate button that is not present. So I was going to wait for the button before updating the website. Yea ok, I'd wait on that too. Keep us posted. On to the Pinned Connection RFC HEre is what I know... We (Autodesk) are going to put that RFC on hold. I personally did not like it. The team who requested it believes they have a workaround which they are investigating as we type. It looks most likely that we will retract it because we can get equivalent functionality from the short transaction API (RFC 78) They actually planned to use it to hold connections for the lifetime of a session. Which is not something I really support having explicit support for in our API. ...but yes, still investigating So after we know if the workaround will work, then we will update the RFC It will either (A) be removed, or (B) be brought back in some form depending on whether the workaround works out Any questions or concerns with this? by session in RFC I always thaught HTTP session I think it is even worse to have it "pinned" as part of MG session that is at leats my first impression Yea me too, that's why I got vocal about it. So Tom - can you update the status of that RFC and somehow mark it as On Hold. And that's also the reason we don't want to make this an API that people would use indiscriminately It would need to be used carefully or scalability and session replication are out the door session replication === failover Yep yes I will mark the RFC as "on hold" my big vote would be for no-session MG I agree with you Bob, gobbling up Fdo connections is a serious scalability issue but having an exposed connection object is more in line with other apis (java and .Net). Not sure if there is a way to force the connections back into the pool after a specific period of time. Session lifetime based connections are definitely dangerous. HTTP call lifetime would be better as Haris suggested. done (marking on hold) Also - please erase the voting history. No one who votted on it understood the underlying implications, which is really bad. Sure, there is none --- the previous vote wasn't completed ok There is also a bug related to that RFC, where if you are using a connection and issue another command using the same resource id you get another connection. We want to fix that. I think it's in Bruce's queue of work. That will be fixed as a bug, don't need an RFC for that Yup I'm fixing that up now yes, that is someting to fix Right, just a bug fix It is a bug fix if the provider supports PerCommandThreaded or Multithreaded only btw, Jason is home - sick All providers today or PerConnectionThreaded - except GDAL which is SingleThreaded *are ok hm, there was bug in MG with updates and threading can't remeber more right now, but I do remeber I changed what King.Oracle suports because of this bug Can you send me an email with the details Haris? but that is another story i guess yes, I will Thanks or a ticket number? hope to remember :( Yes a trac ticket # would be nice too :) agree :) ok - if you think of it, send it to Bruce via the mail list. Trevor - can you mark that as an action? for Haris Yes I will Next Item: Haris/Trevor, want to discuss TCP/IP backward compatibility yes, I am working on georest btw, it is here www.georest.org together with Jason and I was unplesanty surprise that I can't use one build for multiple MG versions it turned out that I would need one build for every version of MG because of incosistent serialization/deserialization not incosistent but different Georest uses the web extensions API directly, effectively a 2 tier app going against MapGuide Server? and strangly it is even worse platformbase of MG 2.1 OS will crash MG Ent 2010 server ( strangly ) yes georest is using mapguidecommon, platforbase foundation... to communicate with instance of MG So you are building against the C++ API that underlies PHP, .NET, JAVA? sorry ? georest is c++ http server or isapi or cgi .. then using those MG common libraries (c++) to talk to MG AH and it seems now I cant have one georest But you are linking against a specific build of the C++ code, and of course that cannot speak to older versions of MG which could talk to different MG servers Bob, the problem would also occur with php, .net, java if a 2.0 web extensions tried to talk to a 2.1 server. got it yes yep I found most of isues are about serialization/de Or possibly even a 2.1 RTM web versus 2.1 SP1 server. in which case versioning of those could help Depends Yes. Haris is correct. For this to work, the Server would have to support previous versions of the TCP/IP ops. versioning means we can detect the issue. Actually making it work means supporting multiple stream versions. yes, but mostly it would be about adding new objects or members to existing objects And also be smart enough to send previous version objects back to the client in the response stream. for example latest issue is that MG 2.1 beta doesn't serialize schema name with class definition Maintaining multiple stream versions is lots of work :) hile latest MG 2.1 has schema name why lot of work ? For the case Haris encountered, yes. It is basically an object versioning issue on MgClassDefinition. Lots of work because none of the infrastructure is there. Then once the infrastructure to handle multiple streams is in place you have to maintain all of the different stream versions. It is difficult because the Server needs multiple paths to decode version 2.0, 2.1, 2.x operations and also has to be smart enough to return the correct object signature in response to the operation version. It sounds like we should put the version in the streams, but we will not be updating the web tier or server (infrastructure) to be able to talk to different versions of each other. Right? in streams there are allready few stream versions which are unused right now It is not just a simple task of adding a "Version" piece to the existing serialization/deserialization code and then you are done Well... things like new member would be very easy to support, right ? We could do this in phases Phase 1: Actually make use of stream version and return an error on mismatch Phase 2: Implement logic to handle multiple I would like to add the "Version" to the streams now and then tackle the compatibility as a 2nd phase I see Bob is already typing this :) At least with (1) the behavior would be predictable. Is there a need to implement phase 2 in MG? For what Harris wants, yes. One georest impl - any MG But Harris, could you get by with just (1) for now? Oh, right, he's using the API and not communicating directly with the server right as he should be Third party C++ processing tools could also make use of this. An older version of the processing tool would still work against new MapGuide Servers. yeah, that seems like a lot of work to maintain going forward. Aren't there any other possible solutions? Same would go for "old" versions of third party php,.net,java libraries. I agree with trevor that in the general case, the objects can change in a multitude of ways, and maintaining it is hard, but for the changes I have seen, there is usually an additional field that is added. This is the same as the item being added to the XSD, which easily supports multiple version. There may be other changes, that I am not aware of. I can certainly work with Bruce and others on an RFC to support TCP/IP backward compatibility. There would be a lot of design decisions to make. But I still belive that the integration is too tight, forcing too much logic in the classes that have multiple purposes Who would implement and fund the work? If there is an intermediate layer that parses a "binary JSON" into C++ classes (and back) it would be better I'd vote for an initial RFC that focuses on using versions and supporting the basic use cases. The version logic could be handled in the parser layer I am not completly sure how important it is I am sure we can come up with a solution for this but it would be a lot of work to maintain and test. All contributors would have to agree to do it. It would be a fundamental part of the coding standards. but it looks bad that I can't put out one application which would work with both MG 2.1 and Ent 2010 HarisK: Agreed That's the problem. Currently all developers are facing a recompile for each new version of MapGuide. Then just choose Ent 2010 :) MapGuide: brucedechant * r4330 /trunk/MgDev/Server/src/Common/Manager/ (FdoConnectionManager.cpp FdoConnectionManager.h): MapGuide: Fix for trac ticket 1140 - Add better support for PerCommandThreaded/Mu ltiThreaded FDO providers MapGuide: http://trac.osgeo.org/mapguide/ticket/1140 MapGuide: Notes: MapGuide: - Added a check for PerCommandThreaded/MultiThreaded FDO provider capability MapGuide: - Allow FDO connections to be reused if the underlying FDO provider supports PerCommandThreaded/MultiThreaded Bruce - multi-taksing are we? :) customer choose Yes :) Harris, are you using PHP for development? .Net actually allows you to load multiple version of the same dll, so it would be theoretically possible, but annoying to actually do. Yes, I'm just kidding, but couldn't multiple versions be put out, that are compiled against a particular version then... Tom - yes but that is painful. yes I did just that but had to dig in adsk sanbox to find correct version to use And Haris would need to know our Enterprise revision numbers so he can build against the right version We only release once every 2 years :( and can hope it is right one ...so not so painful but then it doesnt work agains MG 2.0.2 or 2009 or ..:( yea this is a problem, I am just not sure who is going to fund/do the work The problem is exacerbated by 3rd party vendors. If a City subcontracts some library work against MG 2.0 then they have to back to contractor for a library update when they move to 2.1. Make the move harder. There are some good solutions, but its a fair bit of work Do we start with an RFC to figure out a plan of attack and then evaluate how painful it is going to be? yeah :), I will build many georest's trevorw: Sure - at least then it's captured. Tom and/or Bruce: CAn you take an action to put this on our internal backlog of work to be done. I am sure it wont make it into a PRD, but it does not hurt to have it on the list. Ok. Who wants to be on the TCP/IP compat action item? Trevor, Tom & Bruce? I'll mention it to product management Don't forget Haris tomf2: Thanks. Please include me Trevor trevorw: not me, sorry We are a little over time. Any other issues? Then I motion that we adjourn. Do we want an action item summary? Yes please put it in the minutes and send an e-mail to internals. thank you all Ok. I will. Please let me know if I miss something. and thanks for taking notes Trevor. thanks all. bye everyone End of #mapguide buffer Thu Nov 05 13:21:30 2009 }}}