[mapguide-internals] Development questions (was Project Sponsorship)

Tom Fukushima tom.fukushima at autodesk.com
Wed Nov 26 16:09:17 EST 2008 

Got it thanks.

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Kenneth Skovhede, GEOGRAF A/S
Sent: Wednesday, November 26, 2008 1:41 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] Development questions (was Project Sponsorship)

I wrote my experience summary in response to the request for mentoring,
to illustrate what kind of documentation I feel is missing.

I am not asking for info in the ticket, I was asking on the mailing list.
I could find the function for the selectfeatures call, but somehow the
same/similar request keeps entering the request dispatcher, and I
cannot figure out where that happens.

The problem is that the same request enters the dispatcher multiple
times to perform legitimate subtasks, and for each subtask I had to guess
where the subtask would be executed, in order to set the breakpoint
and follow the execution. I managed to do that a few times, but then
failed completely. I remember concluding, that it was not possible,
without some form of package flow documentation.

I found it difficult to ask a specific question, so I just asked for
documentation
regarding the package flow.

I can't remember the exact details.

If/when I get to work on the issue again, I will put forth a specific
request.

Thank you for following up on my request and issue.

Regards, Kenneth Skovhede, GEOGRAF A/S



Tom Fukushima skrev:
> In that ticket what are you asking for?  Are you asking for where to set a breakpoint in the code so that you can debug?
>
> Thanks
> Tom
>
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Kenneth Skovhede, GEOGRAF A/S
> Sent: Wednesday, November 26, 2008 12:01 PM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] Development questions (was Project Sponsorship)
>
> Very nice work with the pictures, and very fast response too!
>
> I am still looking for the answers to get on with ticket #305, but I found
> a workaround, so I am not actively pursuing it right now.
>
> I have no particular unanswered question atm, but
> I will likely have some when I get some more MapGuide
> time in the beginning of next year.
>
> Regards, Kenneth Skovhede, GEOGRAF A/S
>
>
>
> Tom Fukushima skrev:
>
>> Hi Kenneth,
>>
>> Is there any information that you are still looking for outside of complete documentation? That is, do you have a particular targeted questions that perhaps one of the developers could answer or give pointers on?
>>
>> For example, are you still looking for the code that gets called after the request gets dispatched?
>>
>>
>>
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Bruce Dechant
>> Sent: Wednesday, November 26, 2008 10:56 AM
>> To: MapGuide Internals Mail List
>> Subject: RE: [mapguide-internals] RE: Project Sponsorship
>>
>> Kenneth,
>>
>> I agree with you completely that developer documentation is not readily available as it should be.
>> This is being worked on.
>>
>> If you are looking for the HTTP API documentation - that hasn't been written yet and is something we would like to do.
>>
>> The goal here is to completely document the API.
>>
>> I have updated the architecture documentation to include the operation processing information you have requested. http://trac.osgeo.org/mapguide/wiki/MapGuideArchitecture#OperationProcessing
>>
>> Note: There is still lots more to add to the architecture document that I am still working on.
>>
>> Thanks,
>> Bruce
>>
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Kenneth Skovhede, GEOGRAF A/S
>> Sent: Tuesday, November 25, 2008 3:35 PM
>> To: MapGuide Internals Mail List
>> Subject: Re: [mapguide-internals] RE: Project Sponsorship
>>
>> The issue I was trying to fix was:
>> http://trac.osgeo.org/mapguide/ticket/305
>>
>> The issue number reveals that it was some time ago I asked for extra info.
>> What I managed to do was to build everything in debug mode, and start it up.
>> When the request arrives, I have a vague guess at what function will be
>> activated,
>> so I set a breakpoint there. After a little stepping, the request hits
>> the ACE
>> dispatcher code. Since I have no idea where the request is handled, I
>> cannot set
>> a breakpoint there. I am also unable to determine what request are in
>> queue, and why.
>>
>> What I asked for way back then (and I still need to continue tracing the
>> bug) is
>> documentation that explains what types of packages are avalible, where
>> they originate
>> from and how a typical flow of a request goes. From my point of view,
>> that is
>> Core Documentation, which is something I can only see Autodesk producing.
>>
>> This may not repesent the needs of others, but it is what I need to
>> trace that
>> particular issue. And I must say, I am very reluctant to look at the
>> MapGuide
>> code base again until I see such documentation.
>>
>> I also tried to implement this RFC:
>> http://trac.osgeo.org/mapguide/wiki/MapGuideRfc21
>>
>> The breaking point here was the lack of documentation for mapping WebAPI
>> calls
>> to the server methods (too long ago to remember clearly:)).
>>
>> I also tried to fix this issue:
>> http://trac.osgeo.org/mapguide/ticket/272
>>
>> The problem here was missing documentation for the GwsQuery system,
>> which I requested on the mailing lists. (again, very long time ago).
>>
>> Regards, Kenneth Skovhede, GEOGRAF A/S
>>
>>
>>
>> Tom Fukushima skrev:
>>
>>
>>> Hi,
>>>
>>> It's nice to hear what you all are thinking.
>>>
>>> Seeing this, I think that to get other developers involved we need to:
>>> * Get more documentation about the architecture out there.  Bruce has started something here, but what other things are we looking for.
>>> * Help developers when they ask questions.  I monitor for questions on this mailing list, but it looks like I have missed some of Kenneth's questions. If anyone asks development questions on MapGuide-internals they should be answered; feel free to send me a personal email if you don't see any responses.
>>> * Fix the build process.  Actually, on Windows, I find that the build is quite painless.  It is getting the web tier up and running that does me in.  I don't know what we can do here.  On Linux, it seems that the build is painful, but getting everything up and running is easy; I think that Helio is working on this.
>>> * Is there anything else?
>>>
>>> Also, working to fix a particular defect is a good way for a developer to get started.
>>>
>>> The above said, I don't want to spend a lot of time getting a developer up to speed who will only be working on the project for a short time (e.g., to fix a single defect). So with this in mind, the documentation is probably most important in my mind;  I guess we need to figure out what is needed here.
>>>
>>> BTW, we spent a lot of time looking into the GDAL provider problem recently and did not find any stability problems with GeoTIFF. We were going to update the ticket with the information, but it looks like that hasn't been done yet. There is a memory leak and that will cause a crash after a while, but we don't see any threading problems.  So with MGOS 2.0.2 and GeoTIFF (use GDAL to create these) things are stable.
>>>
>>> Regards,
>>> Tom
>>>
>>>
>>> -----Original Message-----
>>> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Kenneth Skovhede, GEOGRAF A/S
>>> Sent: Monday, November 24, 2008 1:15 AM
>>> To: MapGuide Internals Mail List
>>> Subject: Re: [mapguide-internals] RE: Project Sponsorship
>>>
>>> I find that you and Zac are right to the point.
>>>
>>> I have tried many times over to debug something in MapGuide, but there
>>> is simply
>>> no core documentation avalible. The internal division in request and
>>> response packets
>>> make sense from a performance perspective, but since there is no
>>> documentation
>>> on what the request/response flow is, it is very difficult to trace a
>>> package.
>>>
>>> I have requested such documentation before, but have not seen it yet.
>>>
>>> A mentor would be nice, but for starters, a "core developer guide" would be
>>> more helpfull (to me at least).
>>>
>>> Regards, Kenneth Skovhede, GEOGRAF A/S
>>>
>>>
>>>
>>> Andy Morsell skrev:
>>>
>>>
>>>
>>>> I completely agree that the majority of sponsorship interest from community
>>>> members will be around targeted bug fixes and feature development.  I also
>>>> agree that right now we're very limited by a small group of core developers
>>>> as being our only resource to assist in getting the bugs fixed and the
>>>> features developed.  Most MapGuide users simply do not have the skills to do
>>>> core development work so are reliant on the existing developer group.  The
>>>> existing developers are clearly starting to get frustrated that not many
>>>> other developers are jumping in, but it seems that there just aren't that
>>>> many folks with the right skills to help out in the ways that are needed.
>>>>
>>>> I have actually offered to contribute money more than once (case in point,
>>>> $500 to Frank's plea for help) to specific items and nobody ever took me
>>>> (and others) up on these offers, regardless of whether there was an official
>>>> sponsorship model in place.  Based on this, I'm not overly optimistic that
>>>> it will have much effect unless the individual tasks are able to be treated
>>>> like profitable projects by the developers.  Much the same way it makes
>>>> sense for DM Solutions and other consultants to get paid by clients to do
>>>> development and contribute it back to the project.  Only in this case, it
>>>> wouldn't necessarily be for a specific client, but rather for the project
>>>> itself.
>>>>
>>>> The bottom line: it hasn't seemed to matter how much money we've been
>>>> willing to throw at the project if we don't have the resources to do the
>>>> work...... Perhaps the sponsorship program will draw some worthy developers
>>>> out of the woodwork, so I think it's worth continuing to explore it.
>>>>
>>>>
>>>> Andy Morsell, P.E.
>>>> Spatial Integrators, Inc.
>>>> www.SpatialGIS.com
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: mapguide-internals-bounces at lists.osgeo.org
>>>> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Zac Spitzer
>>>> Sent: Sunday, November 23, 2008 6:00 PM
>>>> To: MapGuide Internals Mail List
>>>> Subject: Re: [mapguide-internals] RE: Project Sponsorship
>>>>
>>>> Generally speaking, aside from general sponsorship for the general
>>>> stuff (build infrastructure), one of the main things
>>>> where i see organisations being interested in sponsorship is very
>>>> targeted bug/feature development.
>>>>
>>>> To take the example of a company or individual deciding for example
>>>> they really need the GDAL FDO provider fixed
>>>> and deciding they want to commit their own resources to fixing this,
>>>> they really need mentoring
>>>>
>>>> The classic example was Frank Warmerdam putting his hand up to resolve
>>>> this bug and asking for assistance from
>>>> a mapguide developer. His requests went unanswered (AFAIKT) and this
>>>> issue remains unresolved.
>>>>
>>>> A similiar example is the CMAKE build process which Helio was (is) working
>>>> on
>>>>
>>>> Currently, nearly all the development on Mapguide is being done via
>>>> Autodesk employees and as a result Autodesk
>>>> have a strong vested interest in the project, but this also forms a
>>>> barrier for external developers to get involved in the project.
>>>>
>>>> Jason's idea of a portal manager, is being performed by the community
>>>> at them moment and that is working reasonably well.
>>>>
>>>> What is really needed is a something like a 'development mentor /
>>>> champion' available within the Autodesk team who can
>>>> assist / guide external developers and capture this information along
>>>> the way, either via wiki articles or via the mailing list.
>>>>
>>>> Making the build process simpler is critical, when a developer can
>>>> simply check the code out and build it and start hacking,
>>>> they are much more likely to actually start developing and
>>>> contributing code back to the project.
>>>>
>>>> The current complexity of the build process means that a lot of people
>>>> start, getting stuck in build issues and loose interest.
>>>>
>>>> http://how2map.blogspot.com/2008/11/mapguide-shaping-up.html
>>>>
>>>> z
>>>>
>>>>
>>>>
>>>> On Mon, Nov 24, 2008 at 11:53 AM, Jason Birch <Jason.Birch at nanaimo.ca>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> I'd prefer to work out the details before going to vote; two votes  will
>>>>>
>>>>>
>>>>>
>>>>>
>>>> just slow down the process.
>>>>
>>>>
>>>>
>>>>
>>>>> Looking at the GDAL and OpenLayers examples, I believe that there are
>>>>>
>>>>>
>>>>>
>>>>>
>>>> quite a few differences in what we could feasibly apply the funds toward at
>>>> this point, primarily because of our developer/user mix.  However, some of
>>>> the important tenets (PSC directs the use of funds, sponsors get full
>>>> reporting on use of funds and feedback through annual questionairres, etc)
>>>> feel right to me.  I also think that we should have a mechanism for
>>>> sponsorship funds to be earmarked for specific PSC-approved projects,
>>>> assuming that at some point we find developers within the community
>>>> interested in undertaking this kind of work.
>>>>
>>>>
>>>>
>>>>
>>>>> Apart from the necessary infrastructure for continuous builds and
>>>>>
>>>>>
>>>>>
>>>>>
>>>> installer packaging, why do we need sponsorship, goals and specifics?  I've
>>>> got some thoughts, but I'd like to hear from everyone.
>>>>
>>>>
>>>>
>>>>
>>>>> Goals:
>>>>>  - Increase the level of community participation in the MapGuide
>>>>>
>>>>>
>>>>>
>>>>>
>>>> development process
>>>>
>>>>
>>>>
>>>>
>>>>>  - Enhance the quality of the project's communications (announcements,
>>>>>
>>>>>
>>>>>
>>>>>
>>>> tickets, release transparency, etc)
>>>>
>>>>
>>>>
>>>>
>>>>>  - Ensure that project is approachable by new users, especially in the
>>>>>
>>>>>
>>>>>
>>>>>
>>>> areas of documentation, code samples, initial install experience, etc.
>>>>
>>>>
>>>>
>>>>
>>>>> Potential uses (examples only, actual PSC-approved expenditures may
>>>>>
>>>>>
>>>>>
>>>>>
>>>> differ):
>>>>
>>>>
>>>>
>>>>
>>>>>  - Maintain project-specific infrastructure necessary to support a fully
>>>>>
>>>>>
>>>>>
>>>>>
>>>> open development environment -- OSGeo takes care of things like Trac, SVN,
>>>> and downloads very well for us, but seems to be under-resourced for
>>>> supporting a continuous build framework, especially for projects such as
>>>> ours which require strong Windows support.
>>>>
>>>>
>>>>
>>>>
>>>>>  - Partial funding for a portal manager, ensuring that tickets are
>>>>>
>>>>>
>>>>>
>>>>>
>>>> followed up, email issues are referred to the Trac system where appropriate,
>>>> new releases are tagged with best possible information on date, etc.
>>>>
>>>>
>>>>
>>>>
>>>>>  - Creation and maintenance of MapGuide installers/packages for a wider
>>>>>
>>>>>
>>>>>
>>>>>
>>>> range of operating systems
>>>>
>>>>
>>>>
>>>>
>>>>> I'm sure there is much more, and maybe some of these aren't in sync with
>>>>>
>>>>>
>>>>>
>>>>>
>>>> everyone's thinking.  There is also some thought to be given to what
>>>> sponsors can expect from this, other than higher quality software and
>>>> community recognition.
>>>>
>>>>
>>>>
>>>>
>>>>> Please let post to the group with your items, etc.  Clearly separate goals
>>>>>
>>>>>
>>>>>
>>>>>
>>>> from potential uses, and ensure that the uses can be tied back to specific
>>>> goals.  Once we get a bit of cohesiveness, this should all go in a wiki for
>>>> collaborative editing.
>>>>
>>>>
>>>>
>>>>
>>>>> For reference:
>>>>>
>>>>> http://www.gdal.org/sponsorship.html
>>>>> http://openlayers.org/sponsorship/
>>>>>
>>>>> Jason
>>>>>
>>>>> ________________________________
>>>>>
>>>>> From: Paul Spencer
>>>>> Sent: Sat 2008-11-22 8:31 AM
>>>>> Subject: Re: [mapguide-internals] RE: Project Sponsorship
>>>>>
>>>>> I'm also in favour of this.  The OpenLayers team has just finished a
>>>>> lengthy discussion on sponsorship and has developed some guidelines of
>>>>> how the sponsorship stuff will work for them (largely based on the
>>>>> GDAL experience and example).  I think we will need to develop a
>>>>> similar set of guidelines for sponsorship for MGOS and have the
>>>>> community and the PSC discuss it before we can formally go that route,
>>>>> but the PSC could vote to agree (or not) on sponsorship in general
>>>>> with the details to be decided on later by a second vote.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mapguide-internals mailing list
>>>>> mapguide-internals at lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> mapguide-internals mailing list
>>> mapguide-internals at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>> _______________________________________________
>>> mapguide-internals mailing list
>>> mapguide-internals at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>
>>>
>>>
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

More information about the mapguide-internals mailing list