[mapguide-internals] Discussion: Taking MapGuide beyond the server/web tier and into the desktop

Carsten Hess carsten.hess at autodesk.com
Mon Jan 4 10:34:19 EST 2010


I think you are all aware but let me still state the obvious. AutoACD Map is basically exactly what you are talking about - MapGuide on the desktop!

It shares the style engine, the data backend, XML and most of the API's, etc.

Most of the integration went into implementing feature service, raster, resource service and pure rendering for the AutoCAD graphics system. Of course there is also a lot of work in the ability to edit features with AutoCAD's great tools and offer other useful tools on top of FDO data.

XML has not been a problem for performance for us nor does it limit us in any way (like undo / redo). Map and MapGuide use the same XML for all resources.


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Trevor Wekel
Sent: Monday, January 04, 2010 10:14 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] Discussion: Taking MapGuide beyond the server/web tier and into the desktop

I have also started a bit of a thought process for a desktop version of MapGuide.

One way to implement the resource service is to simply mirror the repository tree as directories on a file system.  Individual XML documents would simply be files on disk.  If you don't need multi user access and don't care about search, why bother with a database?

The Feature Service will require significant refactoring to pull it out of the Server.  There is a lot of ACE streaming stuff going on in there.  A rewrite is possible but the more reuse a code base gets, the more stable it becomes.  And the Feature Service is already fairly stable.

Mapping and Rendering services may be easier to refactor since the stylization code is already used "elsewhere".


-----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: January 4, 2010 7:20 AM
To: mapguide-internals at lists.osgeo.org
Subject: Re: [mapguide-internals] Discussion: Taking MapGuide beyond the server/web tier and into the desktop

The current XMLDB has terrible performance (IMO).

Stretching the MapGuide Xml into a relational format would require a lot of work, but I would suspect that it would be way faster.

Using something like CouchDB might be easier, but I'm not sure that it is embedable either.

The key features of the XmlDb seems to be:
* validation
* reference searches

The validation is doable with xerces (if not already done this way?).
The reference searches are only done for resourceId properties, depending on the implementation this may be hard to do.

One solution would be to store the xml resources as files, and then keep a database with references, for fast lookup.

I think only author tools (and the the function from rfc 74) use the reference searches.

Regards, Kenneth Skovhede, GEOGRAF A/S

On 04-01-2010 14:12, Jackie Ng wrote:
> Re-posted from Google Wave, because it seems my waves of interest 
> haven't been updated in ages :/
> Just want to start some discussion about another interesting topic: A 
> desktop-based MapGuide API.
> I was bored over the xmas/NY break, so I've been studying the MapGuide 
> source and seeing how the MapGuide Platform API could be applied in a 
> purely desktop-based scenario.
> The MapGuide API offers plenty of functionality in one package. 
> However of the two known implementations:
>     - One has heavy MapGuide Server/Web tier dependencies
>     - One is tightly bound to AutoCAD Map
> What would be really nice, is an implementation of the MapGuide API 
> with *
> little* to *no* such dependencies. The beauty of the FDO API is that 
> in terms of binary footprint, it's simply just a bunch of dlls and one 
> providers.xml files. The client FDO application simply needs to have 
> these libraries in the same directory and they're off and racing. 
> MapGuide unfortunately currently does not have such a rosy deployment story.
> At a high level, implementation of a desktop-based MapGuide API, would 
> seem pretty straight forward. You would be basically implementing your 
> own versions of:
>     - MgFeatureService
>     - MgResourceService
>     - MgMapBase
>     - MgLayerBase
>     - MgSelectionBase
>     - Other Mg* abstract classes
> And the result would be a MapGuide API that is free of any server/web 
> dependencies, and as a result, would also be quite light-weight as well.
> At a lower level, we start to see some roadblocks. Without beating 
> round the bush, the main roadblock here is MgResourceService
> Implementation-wise, everything else looks relatively easy:
>     - MgFeatureService: It's just a wrapper around FDO with utility classes
>     to convert to/from MG and FDO data types.
>     - MgMapBase, MgLayerBase, MgSelectionBase: You could effectively reuse
>     the existing MG implementation here.
>     - In fact, you could base most of the abstract PlatformBase classes from
>     the existing MapGuide implementations.
> MgResourceService uses Berkeley DBXML for the MapGuide implementation, 
> and (I presume) DWG for the AutoCAD Map implementation.
> Unfortunately it seems that DBXML is not usable for a desktop MG 
> implementation due to the un-friendly licensing surrounding the component.
> Thus an alternative is needed for a desktop-based MapGuide implementation.
> I've looked at Jason's suggestion of 
> Sedna<http://modis.ispras.ru/sedna>  as an alternative and it looks 
> like a viable alternative, but there are some issues I've found:
>     - There are no APIs for data store management. I would have to use
>     command-line tools in the Sedna distribution to create/maintain these
>     databases. Ugly.
>     - It is not embeddable :-( The total projected library/executable
>     footprint would probably be just slightly smaller than MapGuide Server
>     itself!
> So while Sedna may give a functional desktop MgResourceService 
> implementation, it's not going to be pretty ugly in the 
> portability/distributable department.
> So my question to you all is: Given the constraints 
> (licensing/technological), what would be the best approach to 
> implementing a desktop-based MgResourceService?
> Do we stay with XML database technology (and live with whatever 
> ugliness it may bring)? Or do we go with something different like a 
> SQLite/Filesystem combo?
> Thoughts?
> - Jackie
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org

More information about the mapguide-internals mailing list