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

[Trevor Wekel]

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".

Thanks,
Trevor



-----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
http://lists.osgeo.org/mailman/listinfo/mapguide-internals