[wiki:ProjectSteeringCommittee Project Steering Committee - Home] == Meeting Info == This meeting of the !MapGuide PSC takes place Thursday, January 14, 2010 at 18:00 UTC (2:00 PM ET / noon MT / 11:00 AM PT). Meeting Chair: Bob Bray Universal Time: http://www.timeanddate.com/worldclock/fixedtime.html?month=01&day=14&year=2010&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 * Cleaning up our Trac Tickets * Thick Client / Future Development Discussion (from mail list)? * GeoREST * documenting the http api * 2.101 point release * Other Items? == Minutes == PSC Members present: Bob, Jason, Bruce, Tom, Haris, Kenneth, Trevor === Cleaning up our Trac Tickets === * Tom will create a wiki for this * Jason will update existing tickets === Thick Client / Future Development Discussion === * Discussion postponed === GeoREST === * Haris will add API documentation === documenting the http api === * Trevor will create initial template and documentation === 2.101 point release === * Mailing list will be used to gather fixed tickets to be included === End of meeting === == Full transcript == {{{ #mapguide [INFO] Channel view for “#mapguide” opened. =-= User mode for dechanb is now +i -->| YOU (dechanb) have joined #mapguide =-= Topic for #mapguide is “MapGuide Open Source | Home: http://mapguide.osgeo.org/ | Bugs: http://trac.osgeo.org/mapguide | See Also: #OSGeo #FDO | Stats: http://www.ohloh.net/projects/4656 -and- http://cia.navi.cx/stats/project/MapGuide” =-= Topic for #mapguide was set by unknown on Thursday, May 29, 2008 1:24:17 PM === #MapGuide http://mapguide.osgeo.org/ -->| lmarcio (n=lmarcio@ns1.pars.com.br) has joined #mapguide -->| fukusht (n=chatzill@adsk-nat-ip11.autodesk.com) has joined #mapguide Bob had to run a quick errand and will be back in a few minutes -->| trevorw (n=trevor_w@96.51.192.151) has joined #mapguide Hey what happened to tomf1? Hi all slowing down in your old age? :) new laptop, I need to reset things lol Hi =-= fukusht is now known as tomf1 -->| rbray (n=rbray@adsk-nat-ip2.autodesk.com) has joined #mapguide Hey sorry I am late... Whew, tom shifted gears in time :) yup Looks like we have a full agenda :) Anyone want to volunteer to take minutes? I will So is there a deterministic algorithm folks use to decide how long to wait before volunteering for that? thk Bruce I was in another window :) rbray: mine approaches infinity -->| Traian_ (n=chatzill@207.35.253.219) has joined #mapguide maybe a roll call would be good, looks like we have Bob, Jason, Bruce, Tom, Haris, Trevor (anyone else)? Traian I meant with a vote? Traian just has opinions - lots of them Just kidding - everyone has a voice. OK - Ticket Cleanup. Any thoughts on how we encourage people to clean up? I'd like to nominate Traian for membership on the PSC... because he's here :) Or are you? ;;) Sorry, out of order... I decline. :) Step one would be to close all old tickets, asking for a re-open if they are still an issue How do other projects manage their ticket database? I believe that most of them assign tickets to individuals and expect those individuals to manage them. I would be fine with closing all the old ones - if everyone else is ok with that approach. But maybe we should adopt a more proactive approach to assigning them to folks going forward We would need a list of candidates on who can take tickets and for what areas Perhaps a wiki page for that would suffice for me I (and I think Jason does as well) review all new tickets that come in and then I could assign it at that time Tom - did I hear you just volunteer to create that Wiki page and the initial list I can create the page, but not the initial list take ticket, is to fix it ? Is there a way to get Trac to automatically assign based on component? I mean list of assignee's Yeah, I don't know what the list of assignee's is trevorw yes And then the assignee can either accept or not It's a tough situation; assuming there is some duplication of effort with ADSK's systems? The majority of developers are still ADSK folks. -->| Kenneth_ (n=chatzill@0x55517824.adsl.cybercity.dk) has joined #mapguide and the assignees would change quite regularly so it would be tough to maintain, are we sure we want to go this route? no - not necessarily Well we can start by closing all the old tickets - how do we define old? I would suggest: removing version and milestone from all enhancement tasks that are not assigned Then go throught and close all 1.2 and lower defects asking for re-open if still a problem. And then go through all 2.0 defects and ask for feedback on 2.1 And come back a month later and close all 2.0 defects that are not responded to. I don't mind doing this. Ah good - a volunteer Thanks Jason - let's start with that We also have to make sure that milestone is not set on tickets that are not going to be addressed. Do we need a vote or ? ok with me Yes, I remove the milestones when I see them. But I haven't done that recently BTW, I've been hacking a few new Trac ticket reports; let me know if there's anything that would be useful. Moving on? yep Next on the agenda - going in order is the Thick Client / Future Dev Thread Not sure where to start with that - other than I am not really in favour of any platform agnostic approach and prefer OpenLayers and/or JavaScript-based solutions. Who's item is this, and what was the intention for having it on the agenda? Trevor's whose? huh. I asked Bob to put it in. I was wondering if we should start a formal thought process around new client technology. I think the first question to ask is - do we need new client technology That's a good question. What pieces of MapGuide do we need to speed up? Client side selection without server intervention might be significant. As I have stated on the mailing list, I recommend that the http API is documented, and expanded to enable all that is possible with the SWiK interface (particularly RuntimeMap manipulation) I would like to approach it from another angle; what is the community asking for and what technologies would help us get there? Once that is ready, a number of clients can be developed completely independent of the MapGuide project Kenneth - I tend to agree There are a few different items here. I agree that that HTTP api needs to be documented and enhanced. I also think that vector-based mapping could give some decent performance benefits, especially for things like editing and maptips. Do we want to formally include GeoREST capability from an ease of use perspective? I have a suggestion, let's move this item to the end of the agenda as GeoREST and HTTP API are next It is already possible to do client side vector rendering, by calling SELECTFEATURES through the HTTP api OL has a GML parser that can read the output and show it as VML/SVG bob: Sure. Sounds like we need to look at HTTP API before viewer technology So let's talk about GeoREST - whose item is that? I suggested and hopping Jason will do most of talking :) I was thining of informing what we have done and some plans about it Cool, then I'll let Haris and Jason have the floor and answer questions if any So, GeoREST in essense is just a feature data HTTP interface, where the user has full control over the output format. Apart from some built-in formats (XML and GeoJSON) Configuration is done via a some XML document And output is templated using google's CTemplate Prettty basic, easy to use, fast. I'm going to have to work to reach the 10 minute mark for my presentation :) The HTML templating is of particular interest to me there is also RESTful API which allows feature queries, editing things like use of plain html forme to search or edit data is posiblle Sounds cool. Is it implemented as mod or? Currently, as ISAPI extension or standalone HTTP server. And where does it get the feature data from, directly from FDO, via the MG Server? Either. Or from cascaded GeoREST server. or to link more GeoREST in one query, like ( parcels under buldings where parcels are serverd by one and building another georest server I am slow :) Sounds cool that it supports direct FDO reads Very cool. I've seen some of the earlier presentations, so I have some insight into the API and it's abilities. seraches can be done in two ways, using syntax usefull for plaint html form or it can be full FDO filter What are the future plans, is the source available? API is not yet documented sourceis available as well as download is basically hosted on Google Code right now http://georest.org Is GeoREST capable of replacing all of the current viewer HTTP calls? No Are you thinking of making it a seperate project? Incorporating it into MGOS? Something else? Not even close :) Decided to fly as separate project initially because of concerns over architecture; wanted to see where it went without tying down to MapGuide :) Trevor, it's really an alteranate Feature Service actually a more capable one with an HTTP API If it proves itself, I think it would be cool to roll it into the MapGuide project in some way. yes Yea I would agree with that as well. But it may be a profile of GeoREST if we need to maintain separation of web/server tiers (we need FDO in web tier) Would it make sense to implement rendering/mapping service as RESTful web services as well and call the whole set a new HTTP API? Yes :) rendering is allready part of it it calls then MapGuide to get image for .png of "resource" trevorw: you've seen this, right? http://trac.osgeo.org/mapguide/wiki/Future/RESTfulWebServices If I unedrstood question correctly jason: yes. I haven't looked at it for a while. As you mentioned future plans, for projects I am working on HarisK: I don't think that the GeoREST rendering supports all of the parameters that the HTTP API does though. AtomPub and something like FDO Servise would be very usefull I believe it passes all parameters so we are using basically same parameters allthough could be wrong but principle is same So... What is the next step. I like the idea, and would love to see it become part of MGOS at some point. btw, we are usng GeoREST for more then a year in 3 customer sites So it has some level of maturity - that is good. Plans for documenting the API? yes that would be next step have some of docs About the same as documenting the MG HTTP API ;) (j/k) just recently become affraid of publishing :) lot of hype what is REST and what is not Personally I'd just like to avoid yet another undocumented API :) we also developed and submtited to OL sandbox two new layers ALthough good samples can go a long way one for image trough GeoREST and another for vectors Agree, I will submit API docs soon we also have some JS libraries we use for easier work with Cool, let's keep this open and discuss it again. Like I said I think the goal should be to add it to MGOS In the meantime, I'll try to find some time to look at the code Let great Oh, and if there are any devs that want to play along, more than happy for others to join the GeoREST PSC ;) Nice... Let's transistion to the HTTP API. Kenneth, that's your item. http api? So, documenting is a priority. But also, parity with the web apis (php/.net). It's an odd mix; some things are only possible via back end, and some via HTTP (recent example of setting DPI for DWF plotting) Ideally, should have all functionality in map agent, so could be pure HTML/JS client framework. Jason: I agree Do we want to extend the existing API or move to REST to do the extension? The existing API works but REST may be more community palatable. So how do we get what we have documented, that will help to identify gaps. Longer term a move to REST is the right thing Is there any way to get the function signatures by spidering the code? But if we have the docs people would be able to use the HTTP API now. I guess documenting the existing API would fall to me. jason: that was the hurdle, we never found a way to automate capturing the docs hence we never produced any Not sure if spidering would work. The parameters are pulled from collections and not C++ function signatures. It was always on the Autodesk list of things to do, but never made it high enough on the priority list to get done I would especially like it documented what data gets stored between HTTP calls, and what is temporarily applied The PHP/Net/Java docs are generated from documentation associated with function signatures. kenneth: Yep. That's a code walk for that level of detail. And it is needed for some APIs. Should we come up with an ordered list of what we want documented first? I can work on it in my spare time and put it up on Trac. Once a function or two is documented, then we can do a bit of divide and conquer as well. Can we get a list of the calls that are supported? that would be an excellent start Could stub out a wiki page with all the names... The Resource Service is fairly easy to understand right away Sure. Good idea. Wiki Page. Mapping/Rendering service are probably the ones that have the greatest viewer impact. If there is a list of API operations avalible, I can write the documentation for some of them, based on my results from numerous experients So Trevor, could you make a list and maybe do a couple of the Mapping/Rendering ones as a template for others to follow? kenneth: HTTP test pages will describe some of them - resource, feature bob: Ok. I will make a list and start on the mapping/rendering ones. trevor: yep, that is what I used to build the MaestroAPI kenneth: did you want to document the ones you are familiar with (resource, feature?) I will do the template first though. trevorw: yep Cool - so we have a plan. We are over time, can everyone hang out long enough to discuss a 2.1.1 point release? I can... still here me too Who can make a short list of fixes that would warrant a point release? So whose item is that? Zac posted the item, but he's not present Couple people have brought it up on the users list. I'm not sure exactly what fixes are important though. Seems like one is a Fusion fix. And there may have been some connection handling bugs fixed post-release. Bruce, which connection bugs were fixed post release? I would have to look at the tickets But there are some? submitted post release? Yes OK - those should be included There is also a base layer selection fix Chris implemented in trunk. Would be good to include as well. Let's start an e-mail thread on internals and get a list together. We don't have to do it here and now. And maybe create a 2.1.1 milestone, and assign the tickets to it? Is the Fusion project near a release that would be worth waiting for? We can add the list of tickets to the 2.1 milestone page. Sounds like a plan. We can ask Fusion about release... Lots of changes there right now; getting ready for something else? :) Yea Paul is not here, so we need to ask those guys. I have not heard, so I don't know. OK I'd suggest we postpone the thick client discussion. Let's get the HTTP API documented and follow GeoRest. And then we'll have something more concrete to discuss with respect to clients. once we know what our server is capable of :) sounds like a plan ok then I motion to adjourn. yep, and I'll run through the initial ticket cleanup. cool - thanks Jason. thanks everyone, let's plan to meet again the first week of Feb. k; bye all |<-- Kenneth_ has left irc.freenode.net ("ChatZilla 0.9.86 [Firefox 3.5.7/20091221164558]") bye later all }}}