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

[Kenneth Skovhede, GEOGRAF A/S]

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
>