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

[Jackie Ng]

Yes, emphasis on the portability. I'm seeing this as another foundational
component on which a desktop-based viewer (or any other desktop application)
could be built on.

- Jackie


Martin Morrison wrote:
> 
> I would presume this would be as a new product (MapGuide Portable?), while
> keeping the existing MapGuide for internet server use?
> 
> Martin
> 
> 
> 
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org
> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jackie Ng
> Sent: Monday, January 04, 2010 8:12 AM
> To: mapguide-internals at lists.osgeo.org
> Subject: [mapguide-internals] Discussion: Taking MapGuide beyond the
> server/web tier and into the desktop
> 
> 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
> -- 
> Blog: http://themapguyde.blogspot.com
> LinkedIn: http://www.linkedin.com/in/jackieng
> Twitter: http://twitter.com/jumpinjackie
> _______________________________________________
> 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
> 
> 

-- 
View this message in context: http://n2.nabble.com/Discussion-Taking-MapGuide-beyond-the-server-web-tier-and-into-the-desktop-tp4249819p4252447.html
Sent from the MapGuide Internals mailing list archive at Nabble.com.