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