Changes between Version 4 and Version 5 of PscMeeting01-14-2010


Ignore:
Timestamp:
Jan 14, 2010 12:30:47 PM (9 years ago)
Author:
brucedechant
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PscMeeting01-14-2010

    v4 v5  
    2424== Minutes ==
    2525
    26 PSC Members present:
     26PSC 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}}}