| 26 | | PSC Members present: |
| | 26 | PSC Members present: Bob, Jason, Bruce, Tom, Haris, Kenneth, Trevor |
| | 27 | |
| | 28 | === Cleaning up our Trac Tickets === |
| | 29 | * Tom will create a wiki for this |
| | 30 | * Jason will update existing tickets |
| | 31 | |
| | 32 | === Thick Client / Future Development Discussion === |
| | 33 | * Discussion postponed |
| | 34 | |
| | 35 | === GeoREST === |
| | 36 | * Haris will add API documentation |
| | 37 | |
| | 38 | === documenting the http api === |
| | 39 | * Trevor will create initial template and documentation |
| | 40 | |
| | 41 | === 2.101 point release === |
| | 42 | * Mailing list will be used to gather fixed tickets to be included |
| | 43 | |
| | 44 | === End of meeting === |
| | 45 | |
| | 46 | == Full transcript == |
| | 47 | {{{ |
| | 48 | #mapguide |
| | 49 | [INFO] Channel view for “#mapguide” opened. |
| | 50 | =-= User mode for dechanb is now +i |
| | 51 | -->| YOU (dechanb) have joined #mapguide |
| | 52 | =-= 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” |
| | 53 | =-= Topic for #mapguide was set by unknown on Thursday, May 29, 2008 1:24:17 PM |
| | 54 | === #MapGuide http://mapguide.osgeo.org/ |
| | 55 | -->| lmarcio (n=lmarcio@ns1.pars.com.br) has joined #mapguide |
| | 56 | -->| fukusht (n=chatzill@adsk-nat-ip11.autodesk.com) has joined #mapguide |
| | 57 | <fukusht> Bob had to run a quick errand and will be back in a few minutes |
| | 58 | -->| trevorw (n=trevor_w@96.51.192.151) has joined #mapguide |
| | 59 | <jasonbirch> Hey what happened to tomf1? |
| | 60 | <dechanb> Hi all |
| | 61 | <jasonbirch> slowing down in your old age? :) |
| | 62 | <fukusht> new laptop, I need to reset things |
| | 63 | <fukusht> lol |
| | 64 | <HarisK> Hi |
| | 65 | =-= fukusht is now known as tomf1 |
| | 66 | -->| rbray (n=rbray@adsk-nat-ip2.autodesk.com) has joined #mapguide |
| | 67 | <rbray> Hey sorry I am late... |
| | 68 | <jasonbirch> Whew, tom shifted gears in time :) |
| | 69 | <tomf1> yup |
| | 70 | <rbray> Looks like we have a full agenda :) |
| | 71 | <rbray> Anyone want to volunteer to take minutes? |
| | 72 | <dechanb> I will |
| | 73 | <rbray> So is there a deterministic algorithm folks use to decide how long to wait before volunteering for that? |
| | 74 | <rbray> thk Bruce |
| | 75 | <dechanb> I was in another window :) |
| | 76 | <jasonbirch> rbray: mine approaches infinity |
| | 77 | -->| Traian_ (n=chatzill@207.35.253.219) has joined #mapguide |
| | 78 | <rbray> maybe a roll call would be good, looks like we have Bob, Jason, Bruce, Tom, Haris, Trevor (anyone else)? |
| | 79 | <jasonbirch> Traian |
| | 80 | <rbray> I meant with a vote? Traian just has opinions - lots of them |
| | 81 | <rbray> Just kidding - everyone has a voice. |
| | 82 | <rbray> OK - Ticket Cleanup. Any thoughts on how we encourage people to clean up? |
| | 83 | <jasonbirch> I'd like to nominate Traian for membership on the PSC... because he's here :) |
| | 84 | <Traian_> Or are you? ;;) |
| | 85 | <jasonbirch> Sorry, out of order... |
| | 86 | <Traian_> I decline. |
| | 87 | <jasonbirch> :) |
| | 88 | <jasonbirch> Step one would be to close all old tickets, asking for a re-open if they are still an issue |
| | 89 | <rbray> How do other projects manage their ticket database? |
| | 90 | <jasonbirch> I believe that most of them assign tickets to individuals and expect those individuals to manage them. |
| | 91 | <rbray> I would be fine with closing all the old ones - if everyone else is ok with that approach. |
| | 92 | <rbray> But maybe we should adopt a more proactive approach to assigning them to folks |
| | 93 | <rbray> going forward |
| | 94 | <tomf1> We would need a list of candidates on who can take tickets and for what areas |
| | 95 | <tomf1> Perhaps a wiki page for that would suffice for me |
| | 96 | <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 |
| | 97 | <rbray> Tom - did I hear you just volunteer to create that Wiki page and the initial list |
| | 98 | <tomf1> I can create the page, but not the initial list |
| | 99 | <HarisK> take ticket, is to fix it ? |
| | 100 | <trevorw> Is there a way to get Trac to automatically assign based on component? |
| | 101 | <rbray> I mean list of assignee's |
| | 102 | <tomf1> Yeah, I don't know what the list of assignee's is |
| | 103 | <jasonbirch> trevorw yes |
| | 104 | <jasonbirch> And then the assignee can either accept or not |
| | 105 | <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. |
| | 106 | -->| Kenneth_ (n=chatzill@0x55517824.adsl.cybercity.dk) has joined #mapguide |
| | 107 | <tomf1> and the assignees would change quite regularly so it would be tough to maintain, are we sure we want to go this route? |
| | 108 | <rbray> no - not necessarily |
| | 109 | <rbray> Well we can start by closing all the old tickets - how do we define old? |
| | 110 | <jasonbirch> I would suggest: removing version and milestone from all enhancement tasks that are not assigned |
| | 111 | <jasonbirch> Then go throught and close all 1.2 and lower defects asking for re-open if still a problem. |
| | 112 | <jasonbirch> And then go through all 2.0 defects and ask for feedback on 2.1 |
| | 113 | <jasonbirch> And come back a month later and close all 2.0 defects that are not responded to. |
| | 114 | <jasonbirch> I don't mind doing this. |
| | 115 | <rbray> Ah good - a volunteer |
| | 116 | <rbray> Thanks Jason - let's start with that |
| | 117 | <jasonbirch> We also have to make sure that milestone is not set on tickets that are not going to be addressed. |
| | 118 | <rbray> Do we need a vote or ? |
| | 119 | <HarisK> ok with me |
| | 120 | <tomf1> Yes, I remove the milestones when I see them. But I haven't done that recently |
| | 121 | <jasonbirch> BTW, I've been hacking a few new Trac ticket reports; let me know if there's anything that would be useful. |
| | 122 | <jasonbirch> Moving on? |
| | 123 | <rbray> yep |
| | 124 | <rbray> Next on the agenda - going in order is the Thick Client / Future Dev Thread |
| | 125 | <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. |
| | 126 | <jasonbirch> Who's item is this, and what was the intention for having it on the agenda? |
| | 127 | <rbray> Trevor's |
| | 128 | <jasonbirch> whose? huh. |
| | 129 | <trevorw> I asked Bob to put it in. I was wondering if we should start a formal thought process around new client technology. |
| | 130 | <rbray> I think the first question to ask is - do we need new client technology |
| | 131 | <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. |
| | 132 | <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) |
| | 133 | <tomf1> I would like to approach it from another angle; what is the community asking for and what technologies would help us get there? |
| | 134 | <Kenneth_> Once that is ready, a number of clients can be developed completely independent of the MapGuide project |
| | 135 | <rbray> Kenneth - I tend to agree |
| | 136 | <jasonbirch> There are a few different items here. I agree that that HTTP api needs to be documented and enhanced. |
| | 137 | <jasonbirch> I also think that vector-based mapping could give some decent performance benefits, especially for things like editing and maptips. |
| | 138 | <trevorw> Do we want to formally include GeoREST capability from an ease of use perspective? |
| | 139 | <rbray> I have a suggestion, let's move this item to the end of the agenda as GeoREST and HTTP API are next |
| | 140 | <Kenneth_> It is already possible to do client side vector rendering, by calling SELECTFEATURES through the HTTP api |
| | 141 | <Kenneth_> OL has a GML parser that can read the output and show it as VML/SVG |
| | 142 | <trevorw> bob: Sure. Sounds like we need to look at HTTP API before viewer technology |
| | 143 | <rbray> So let's talk about GeoREST - whose item is that? |
| | 144 | <HarisK> I suggested and hopping Jason will do most of talking :) |
| | 145 | <HarisK> I was thining of informing what we have done and some plans about it |
| | 146 | <rbray> Cool, then I'll let Haris and Jason have the floor |
| | 147 | <HarisK> and answer questions if any |
| | 148 | <jasonbirch> So, GeoREST in essense is just a feature data HTTP interface, where the user has full control over the output format. |
| | 149 | <jasonbirch> Apart from some built-in formats (XML and GeoJSON) |
| | 150 | <jasonbirch> Configuration is done via a some XML document |
| | 151 | <jasonbirch> And output is templated using google's CTemplate |
| | 152 | <jasonbirch> Prettty basic, easy to use, fast. |
| | 153 | <jasonbirch> I'm going to have to work to reach the 10 minute mark for my presentation :) |
| | 154 | <jasonbirch> The HTML templating is of particular interest to me |
| | 155 | <HarisK> there is also RESTful API which allows feature queries, editing |
| | 156 | <HarisK> things like use of plain html forme to search or edit data is posiblle |
| | 157 | <rbray> Sounds cool. Is it implemented as mod or? |
| | 158 | <jasonbirch> Currently, as ISAPI extension or standalone HTTP server. |
| | 159 | <rbray> And where does it get the feature data from, directly from FDO, via the MG Server? |
| | 160 | <jasonbirch> Either. |
| | 161 | <jasonbirch> Or from cascaded GeoREST server. |
| | 162 | <HarisK> or to link more GeoREST in one query, like ( parcels under buldings where parcels are serverd by one and building another georest server |
| | 163 | <HarisK> I am slow :) |
| | 164 | <Kenneth_> Sounds cool that it supports direct FDO reads |
| | 165 | <rbray> Very cool. I've seen some of the earlier presentations, so I have some insight into the API and it's abilities. |
| | 166 | <HarisK> seraches can be done in two ways, using syntax usefull for plaint html form |
| | 167 | <HarisK> or it can be full FDO filter |
| | 168 | <rbray> What are the future plans, is the source available? |
| | 169 | <HarisK> API is not yet documented |
| | 170 | <HarisK> sourceis available as well as download |
| | 171 | <jasonbirch> is basically hosted on Google Code right now http://georest.org |
| | 172 | <trevorw> Is GeoREST capable of replacing all of the current viewer HTTP calls? |
| | 173 | <jasonbirch> No |
| | 174 | <rbray> Are you thinking of making it a seperate project? Incorporating it into MGOS? Something else? |
| | 175 | <jasonbirch> Not even close :) |
| | 176 | <jasonbirch> Decided to fly as separate project initially because of concerns over architecture; wanted to see where it went without tying down to MapGuide :) |
| | 177 | <rbray> Trevor, it's really an alteranate Feature Service |
| | 178 | <rbray> actually a more capable one with an HTTP API |
| | 179 | <jasonbirch> If it proves itself, I think it would be cool to roll it into the MapGuide project in some way. |
| | 180 | <HarisK> yes |
| | 181 | <rbray> Yea I would agree with that as well. |
| | 182 | <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) |
| | 183 | <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? |
| | 184 | <jasonbirch> Yes :) |
| | 185 | <HarisK> rendering is allready part of it |
| | 186 | <HarisK> it calls then MapGuide to get image |
| | 187 | <HarisK> for .png of "resource" |
| | 188 | <jasonbirch> trevorw: you've seen this, right? http://trac.osgeo.org/mapguide/wiki/Future/RESTfulWebServices |
| | 189 | <HarisK> If I unedrstood question correctly |
| | 190 | <trevorw> jason: yes. I haven't looked at it for a while. |
| | 191 | <HarisK> As you mentioned future plans, for projects I am working on |
| | 192 | <jasonbirch> HarisK: I don't think that the GeoREST rendering supports all of the parameters that the HTTP API does though. |
| | 193 | <HarisK> AtomPub and something like FDO Servise would be very usefull |
| | 194 | <HarisK> I believe it passes all parameters |
| | 195 | <HarisK> so we are using basically same parameters |
| | 196 | <HarisK> allthough could be wrong |
| | 197 | <HarisK> but principle is same |
| | 198 | <rbray> So... What is the next step. I like the idea, and would love to see it become part of MGOS at some point. |
| | 199 | <HarisK> btw, we are usng GeoREST for more then a year in 3 customer sites |
| | 200 | <rbray> So it has some level of maturity - that is good. Plans for documenting the API? |
| | 201 | <HarisK> yes that would be next step |
| | 202 | <HarisK> have some of docs |
| | 203 | <jasonbirch> About the same as documenting the MG HTTP API ;) (j/k) |
| | 204 | <HarisK> just recently become affraid of publishing :) |
| | 205 | <HarisK> lot of hype what is REST and what is not |
| | 206 | <rbray> Personally I'd just like to avoid yet another undocumented API :) |
| | 207 | <HarisK> we also developed and submtited to OL sandbox |
| | 208 | <HarisK> two new layers |
| | 209 | <rbray> ALthough good samples can go a long way |
| | 210 | <HarisK> one for image trough GeoREST |
| | 211 | <HarisK> and another for vectors |
| | 212 | <HarisK> Agree, I will submit API docs soon |
| | 213 | <HarisK> we also have some JS libraries we use for easier work with |
| | 214 | <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 |
| | 215 | <rbray> In the meantime, I'll try to find some time to look at the code |
| | 216 | <rbray> Let |
| | 217 | <HarisK> great |
| | 218 | <jasonbirch> Oh, and if there are any devs that want to play along, more than happy for others to join the GeoREST PSC ;) |
| | 219 | <rbray> Nice... |
| | 220 | <rbray> Let's transistion to the HTTP API. |
| | 221 | <rbray> Kenneth, that's your item. |
| | 222 | <Kenneth_> http api? |
| | 223 | <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) |
| | 224 | <jasonbirch> Ideally, should have all functionality in map agent, so could be pure HTML/JS client framework. |
| | 225 | <rbray> Jason: I agree |
| | 226 | <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. |
| | 227 | <rbray> So how do we get what we have documented, that will help to identify gaps. |
| | 228 | <rbray> Longer term a move to REST is the right thing |
| | 229 | <jasonbirch> Is there any way to get the function signatures by spidering the code? |
| | 230 | <rbray> But if we have the docs people would be able to use the HTTP API now. |
| | 231 | <trevorw> I guess documenting the existing API would fall to me. |
| | 232 | <rbray> jason: that was the hurdle, we never found a way to automate capturing the docs |
| | 233 | <rbray> hence we never produced any |
| | 234 | <trevorw> Not sure if spidering would work. The parameters are pulled from collections and not C++ function signatures. |
| | 235 | <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 |
| | 236 | <Kenneth_> I would especially like it documented what data gets stored between HTTP calls, and what is temporarily applied |
| | 237 | <trevorw> The PHP/Net/Java docs are generated from documentation associated with function signatures. |
| | 238 | <trevorw> kenneth: Yep. That's a code walk for that level of detail. And it is needed for some APIs. |
| | 239 | <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. |
| | 240 | <rbray> Once a function or two is documented, then we can do a bit of divide and conquer as well. |
| | 241 | <jasonbirch> Can we get a list of the calls that are supported? |
| | 242 | <rbray> that would be an excellent start |
| | 243 | <jasonbirch> Could stub out a wiki page with all the names... |
| | 244 | <Kenneth_> The Resource Service is fairly easy to understand right away |
| | 245 | <trevorw> Sure. Good idea. Wiki Page. Mapping/Rendering service are probably the ones that have the greatest viewer impact. |
| | 246 | <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 |
| | 247 | <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? |
| | 248 | <trevorw> kenneth: HTTP test pages will describe some of them - resource, feature |
| | 249 | <trevorw> bob: Ok. I will make a list and start on the mapping/rendering ones. |
| | 250 | <Kenneth_> trevor: yep, that is what I used to build the MaestroAPI |
| | 251 | <trevorw> kenneth: did you want to document the ones you are familiar with (resource, feature?) |
| | 252 | <trevorw> I will do the template first though. |
| | 253 | <Kenneth_> trevorw: yep |
| | 254 | <rbray> Cool - so we have a plan. |
| | 255 | <rbray> We are over time, can everyone hang out long enough to discuss a 2.1.1 point release? |
| | 256 | <jasonbirch> I can... |
| | 257 | <dechanb> still here |
| | 258 | <HarisK> me too |
| | 259 | <Kenneth_> Who can make a short list of fixes that would warrant a point release? |
| | 260 | <rbray> So whose item is that? |
| | 261 | <Kenneth_> Zac posted the item, but he's not present |
| | 262 | <jasonbirch> Couple people have brought it up on the users list. |
| | 263 | <jasonbirch> I'm not sure exactly what fixes are important though. |
| | 264 | <jasonbirch> Seems like one is a Fusion fix. |
| | 265 | <jasonbirch> And there may have been some connection handling bugs fixed post-release. |
| | 266 | <rbray> Bruce, which connection bugs were fixed post release? |
| | 267 | <dechanb> I would have to look at the tickets |
| | 268 | <rbray> But there are some? |
| | 269 | <rbray> submitted post release? |
| | 270 | <dechanb> Yes |
| | 271 | <rbray> OK - those should be included |
| | 272 | <trevorw> There is also a base layer selection fix Chris implemented in trunk. Would be good to include as well. |
| | 273 | <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. |
| | 274 | <rbray> And maybe create a 2.1.1 milestone, and assign the tickets to it? |
| | 275 | <Kenneth_> Is the Fusion project near a release that would be worth waiting for? |
| | 276 | <tomf1> We can add the list of tickets to the 2.1 milestone page. |
| | 277 | <jasonbirch> Sounds like a plan. We can ask Fusion about release... |
| | 278 | <jasonbirch> Lots of changes there right now; getting ready for something else? :) |
| | 279 | <rbray> Yea Paul is not here, so we need to ask those guys. |
| | 280 | <rbray> I have not heard, so I don't know. |
| | 281 | <rbray> OK I'd suggest we postpone the thick client discussion. Let's get the HTTP API documented and follow GeoRest. |
| | 282 | <rbray> And then we'll have something more concrete to discuss with respect to clients. |
| | 283 | <rbray> once we know what our server is capable of :) |
| | 284 | <dechanb> sounds like a plan |
| | 285 | <rbray> ok then I motion to adjourn. |
| | 286 | <jasonbirch> yep, and I'll run through the initial ticket cleanup. |
| | 287 | <rbray> cool - thanks Jason. |
| | 288 | <rbray> thanks everyone, let's plan to meet again the first week of Feb. |
| | 289 | <jasonbirch> k; bye all |
| | 290 | |<-- Kenneth_ has left irc.freenode.net ("ChatZilla 0.9.86 [Firefox 3.5.7/20091221164558]") |
| | 291 | <HarisK> bye |
| | 292 | <dechanb> later all |
| | 293 | }}} |
