[FGS] FGS future direction

Paul Spencer pspencer at dmsolutions.ca
Thu Apr 19 12:42:55 EDT 2007


Daniel,

thanks for taking the lead on this :)  I can confirm that DMSG  
actively uses FGS in client projects and we (well, Shawn Barnes) are  
building some experience with fgs-dev.  It seems likely we can  
continue to contribute to FGS over time as well, as supporting our  
clients with new versions of the main libraries is important  
(MapServer, GDAL, PROJ, Apache, PHP, etc, etc, etc).

As you mentioned, we are engaged in a project to get MapGuide  
building inside the FGS environment.  This has some unique problems,  
but I do not think we will need to make significant changes to fgs- 
dev to get it working.

We also had a need to package the lighttpd web server instead of  
Apache, and that did cause significant problems.  Right now, that is  
essentially a fork of the core fgs-dev since fgs-dev is VERY Apache- 
centric.  I believe that some effort on this would bring the two back  
in line and make it optional to build FGS with one web server or the  
other.  However, given tight time lines, we weren't able to solve all  
the problems and resorted to a bit of a hack ...

Finally, Shawn has managed to put together some rough documentation  
on the structure of FGS and what it takes to build fgs-dev and add  
new packages to it.  If we can whip this into more formal  
documentation with help of the community, then it would encourage  
other groups to perhaps contribute modules for their software.

Shawn has been using VMs for a while, and it seems like this is the  
best way to build FGS.  It certainly makes it easier to build a more  
portable FGS.  It may also make a very nice way to distribute binary  
builds of FGS pre-packaged with a linux OS for the growing number of  
folks that are into virtualization using VMs ...

I highly recommend that we pursue the establishment of a PSC and  
further recommend that FGS seek a home inside OSGeo either as an  
official project or just to use the telascience infrastructure for a  
shared build environment (they are doing a lot of stuff with buildbot  
etc using VMs and it seems a natural fit).

I nominate Shawn to be a member of the PSC as he is likely the most  
active developer of it right now, and is probably the most familiar  
with how it actually works (other than Guillaume).

Cheers

Paul

On 19-Apr-07, at 12:08 PM, Daniel Morissette wrote:

> Hi everyone,
>
> The FGS project has been a bit quiet lately. We're still using it  
> internally, but not much is happening on the open source/public  
> front. This is mostly because Guillaume is no longer working on it  
> full time (he has another full time job), so the project is kind of  
> orphan right now. I think FGS serves a very useful purpose (at  
> least it does for us and our clients), and I think we should give  
> it a little boost to take it to the next level.
>
> First of all I would like to find out who, outside of Mapgears and  
> DM Solutions uses FGS actively or has an interest in it, and how it  
> is being used.
>
> There is some work going on right now to build a FGS package for  
> the Open Source MapGuide (http://mapguide.osgeo.org/) but MapGuide  
> is huge and there are issues with MapGuide that may require changes  
> to FGS. I'd like to ensure that whatever is done for MapGuide will  
> remain compatible with other packages and be viable for the long run.
>
> To address the above, I'd like to propose the following draft  
> roadmap for FGS:
>
> 1- Setup a FGS Project Steering Committee (PSC) that would be in  
> charge of leading the future of FGS
>
> 2- Plan for a new release (0.3) that would address some of the  
> issues with 0.2.
>
> 3- Setup a VM-based build environment that can be shared by all  
> developers to compile/distribute compatible FGS packages. This  
> should address the problems with the current 0.2 packages on the  
> download site which were compiled on a fairly recent Debian system  
> and are not as portable as the 0.1 packages which were built on an  
> older system and really worked virtually anywhere. If we all use  
> the same VM based on the same architecture as what was used by 0.1  
> then all developers could compile packages that work(!), and that  
> are compatible with each other.
>
> 4- Plan for a 1.0 release (possibly just take 0.3 and call it 1.0)
>
> Please share your thoughts...
>
> Daniel
> -- 
> Daniel Morissette
> http://www.mapgears.com/
> _______________________________________________
> Foss-gis-suite mailing list
> Foss-gis-suite at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/foss-gis-suite

+-----------------------------------------------------------------+
|Paul Spencer                          pspencer at dmsolutions.ca    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+






More information about the Foss-gis-suite mailing list