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