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 ​#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
<rbray> 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
<rbray> Anyone care to take minutes?
<trevorw> I think I did last time, does that exclude me this time?
<rbray> Not at all - regular suckers welcome
<rbray> oh I mean volunteers
<trevorw> 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
<rbray> Last I looked we only have one agenda item - 2.1 Release Update
<trevorw> 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.
<trevorw> (oops.  TCP/IP backward compat)
<rbray> ok
<trevorw> I can also give a one liner update on the Sponsorship RFC.
<rbray> ok
<rbray> Let's start with the release.
<rbray> If I read through the lines of Crispin's e-mail he was asking us to release based 
  on RC1. Any thoughts or opinions?
<bdechant> We need to release - it is long overdue.
<trevorw> 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?
<HarisK> we are using 2.1 latest Jason builds in couple production sites
<rbray> So does anyone think we should not release 2.1 now?
<rbray> Silence speaks. So then I will offically motion to release 2.1.
<tomf2> +1
<rbray> +1 from me (it's way overdue)
<trevorw> +1 Trevor - we may need to rebrand the installer.  I can check with Jason.
<HarisK> +1
<bdechant> +1
<trevorw> Is Kenneth online?  He shows up in my IRC list.
<rbray> OK - Motion passed.
<rbray> Trevor, any basic rebrand is fine. When do you think we can get a build?
<trevorw> I'm not sure.  Jason was handling the 2.1 release.  I will ping him after the 
  meeting.
<trevorw> I will add it as an action item - rebrand and send out official release ASAP.
<rbray> Cool thanks.
<rbray> Want to give us your sponsorship update next?
<trevorw> 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.
<trevorw> 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.
<trevorw> 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.
<trevorw> So I was going to wait for the button before updating the website.
<rbray> Yea ok, I'd wait on that too.
<rbray> Keep us posted.
<rbray> On to the Pinned Connection RFC
<rbray> HEre is what I know...
<rbray> We (Autodesk) are going to put that RFC on hold.
<rbray> I personally did not like it. The team who requested it believes they have a 
  workaround which they are investigating as we type.
<tomf2> It looks most likely that we will retract it because we can get equivalent 
  functionality from the short transaction API (RFC 78)
<rbray> 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.
<tomf2> ...but yes, still investigating
<rbray> So after we know if the workaround will work, then we will update the RFC
<rbray> It will either (A) be removed, or (B) be brought back in some form
<rbray> depending on whether the workaround works out
<rbray> Any questions or concerns with this?
<HarisK> by session in RFC I always thaught HTTP session
<HarisK> I think it is even worse to have it "pinned" as part of MG session
<HarisK> that is at leats my first impression
<rbray> Yea me too, that's why I got vocal about it.
<rbray> So Tom - can you update the status of that RFC and somehow mark it as On Hold.
<tomf2> And that's also the reason we don't want to make this an API that people would use 
  indiscriminately
<tomf2> It would need to be used carefully or scalability and session replication are out 
  the door
<tomf2> session replication === failover
<rbray> Yep
<HarisK> yes
<tomf2> I will mark the RFC as "on hold"
<HarisK> my big vote would be for no-session MG
<trevorw> 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.
<tomf2> done (marking on hold)
<rbray> Also - please erase the voting history.
<rbray> No one who votted on it understood the underlying implications, which is really 
  bad.
<tomf2> Sure, there is none --- the previous vote wasn't completed
<rbray> ok
<rbray> 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.
<rbray> We want to fix that. I think it's in Bruce's queue of work.
<tomf2> That will be fixed as a bug, don't need an RFC for that
<bdechant> Yup I'm fixing that up now
<HarisK> yes, that is someting to fix
<rbray> Right, just a bug fix
<bdechant> It is a bug fix if the provider supports PerCommandThreaded or Multithreaded 
  only
<HarisK> btw, Jason is home - sick
<bdechant> All providers today or PerConnectionThreaded - except GDAL which is 
  SingleThreaded
<bdechant> *are
<rbray> ok
<HarisK> hm, there was bug in MG with updates and threading
<HarisK> can't remeber more right now, but I do remeber I changed what King.Oracle suports 
  because of this bug
<bdechant> Can you send me an email with the details Haris?
<HarisK> but that is another story i guess
<HarisK> yes, I will
<bdechant> Thanks
<rbray> or a ticket number?
<HarisK> hope to remember
<HarisK> :(
<bdechant> Yes a trac ticket # would be nice too :)
<HarisK> agree :)
<rbray> ok - if you think of it, send it to Bruce via the mail list.
<rbray> Trevor - can you mark that as an action?
<rbray> for Haris
<trevorw> Yes I will
<rbray> Next Item: Haris/Trevor, want to discuss TCP/IP backward compatibility
<HarisK> yes, I am working on georest
<HarisK> btw, it is here www.georest.org
<HarisK> together with Jason
<HarisK> and I was unplesanty surprise that I can't use one build for multiple MG versions
<HarisK> it turned out that I would need one build for every version of MG
<HarisK> because of incosistent serialization/deserialization
<HarisK> not incosistent but different
<trevorw> Georest uses the web extensions API directly, effectively a 2 tier app going 
  against MapGuide Server?
<HarisK> and strangly it is even worse
<HarisK> platformbase of MG 2.1 OS will crash MG Ent 2010 server ( strangly )
<HarisK> yes
<HarisK> georest is using mapguidecommon, platforbase foundation...
<HarisK> to communicate with instance of MG
<rbray> So you are building against the C++ API that underlies PHP, .NET, JAVA?
<HarisK> sorry ?
<HarisK> georest is c++
<HarisK> http server or isapi or cgi ..
<HarisK> then using those MG common libraries (c++) to talk to MG
<rbray> AH
<HarisK> and it seems now I cant have one georest
<rbray> But you are linking against a specific build of the C++ code, and of course that 
  cannot speak to older versions of MG
<HarisK> which could talk to different MG servers
<trevorw> Bob, the problem would also occur with php, .net, java if a 2.0 web extensions 
  tried to talk to a 2.1 server.
<rbray> got it
<HarisK> yes
<rbray> yep
<HarisK> I found most of isues are about serialization/de
<trevorw> Or possibly even a 2.1 RTM web versus 2.1 SP1 server.
<HarisK> in which case versioning of those could help
<rbray> Depends
<trevorw> Yes.  Haris is correct.  For this to work, the Server would have to support 
  previous versions of the TCP/IP ops.
<rbray> versioning means we can detect the issue.
<rbray> Actually making it work means supporting multiple stream versions.
<HarisK> yes, but mostly it would be about adding new objects or members to existing 
  objects
<trevorw> And also be smart enough to send previous version objects back to the client in 
  the response stream.
<HarisK> for example latest issue is that MG 2.1 beta doesn't serialize schema name with 
  class definition
<bdechant> Maintaining multiple stream versions is lots of work :)
<HarisK> hile latest MG 2.1 has schema name
<HarisK> why lot of work ?
<trevorw> For the case Haris encountered, yes.  It is basically an object versioning issue 
  on MgClassDefinition.
<bdechant> 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.
<trevorw> 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.
<tomf2> 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?
<HarisK> in streams there are allready few stream versions which are unused right now
<bdechant> It is not just a simple task of adding a "Version" piece to the existing 
  serialization/deserialization code and then you are done
<rbray> Well...
<HarisK> things like new member would be very easy to support, right ?
<rbray> We could do this in phases
<rbray> Phase 1: Actually make use of stream version and return an error on mismatch
<rbray> Phase 2: Implement logic to handle multiple
<bdechant> I would like to add the "Version" to the streams now and then tackle the 
  compatibility as a 2nd phase
<bdechant> I see Bob is already typing this :)
<rbray> At least with (1) the behavior would be predictable.
<tomf2> Is there a need to implement phase 2 in MG?
<rbray> For what Harris wants, yes. One georest impl - any MG
<rbray> But Harris, could you get by with just (1) for now?
<tomf2> Oh, right, he's using the API and not communicating directly with the server
<rbray> right
<rbray> as he should be
<trevorw> 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.
<tomf2> yeah, that seems like a lot of work to maintain going forward.  Aren't there any 
  other possible solutions?
<trevorw> Same would go for "old" versions of third party php,.net,java libraries.
<Kenneth_> 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.
<Kenneth_> There may be other changes, that I am not aware of.
<trevorw> 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.
<Kenneth_> But I still belive that the integration is too tight, forcing too much logic in 
  the classes that have multiple purposes
<tomf2> Who would implement and fund the work?
<Kenneth_> If there is an intermediate layer that parses a "binary JSON" into C++ classes 
  (and back) it would be better
<rbray> I'd vote for an initial RFC that focuses on using versions and supporting the 
  basic use cases.
<Kenneth_> The version logic could be handled in the parser layer
<HarisK> I am not completly sure how important it is
<trevorw> 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.
<HarisK> but it looks bad that I can't put out one application which would work with both 
  MG 2.1 and Ent 2010
<rbray> HarisK: Agreed
<trevorw> That's the problem.  Currently all developers are facing a recompile for each 
  new version of MapGuide.
<tomf2> Then just choose Ent 2010 :)
<CIA-35> MapGuide: brucedechant * r4330 /trunk/MgDev/Server/src/Common/Manager/ 
  (FdoConnectionManager.cpp FdoConnectionManager.h):
<CIA-35> MapGuide: Fix for trac ticket 1140 - Add better support for PerCommandThreaded/Mu
  ltiThreaded FDO providers
<CIA-35> MapGuide: http://trac.osgeo.org/mapguide/ticket/1140
<CIA-35> MapGuide: Notes:
<CIA-35> MapGuide: - Added a check for PerCommandThreaded/MultiThreaded FDO provider 
  capability
<CIA-35> MapGuide: - Allow FDO connections to be reused if the underlying FDO provider 
  supports PerCommandThreaded/MultiThreaded
<rbray> Bruce - multi-taksing are we?
<HarisK> :) customer choose
<bdechant> Yes :)
<Kenneth_> 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.
<tomf2> Yes, I'm just kidding, but couldn't multiple versions be put out, that are 
  compiled against a particular version then...
<rbray> Tom - yes but that is painful.
<HarisK> yes I did just that
<HarisK> but had to dig in adsk sanbox
<HarisK> to find correct version to use
<rbray> And Haris would need to know our Enterprise revision numbers so he can build 
  against the right version
<tomf2> We only release once every 2 years :(
<HarisK> and can hope it is right one
<tomf2> ...so not so painful
<HarisK> but then it doesnt work agains MG 2.0.2 or 2009 or ..:(
<rbray> yea this is a problem, I am just not sure who is going to fund/do the work
<trevorw> 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.
<rbray> There are some good solutions, but its a fair bit of work
<trevorw> Do we start with an RFC to figure out a plan of attack and then evaluate how 
  painful it is going to be?
<HarisK> yeah :), I will build many georest's
<rbray> trevorw: Sure - at least then it's captured.
<rbray> 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.
<trevorw> Ok.  Who wants to be on the TCP/IP compat action item?  Trevor, Tom & Bruce?
<tomf2> I'll mention it to product management
<rbray> Don't forget Haris
<rbray> tomf2: Thanks.
<bdechant> Please include me Trevor
<tomf2> trevorw: not me, sorry
<rbray> We are a little over time. Any other issues?
<rbray> Then I motion that we adjourn.
<trevorw> Do we want an action item summary?
<rbray> Yes please put it in the minutes and send an e-mail to internals.
<HarisK> thank you all
<trevorw> Ok.  I will.  Please let me know if I miss something.
<rbray> and thanks for taking notes Trevor.
<rbray> thanks all.
<bdechant> bye everyone
End of #mapguide buffer    Thu Nov 05 13:21:30 2009