[mapguide-internals] Feature Service application layer (was: Standardising FDO Schema's)

[Jason Birch]

Hmm.  This discussion seems like it should include the MapGuide folks :)

I would be hesitant to support the packaging of a platform service that
had a dependence on DBXML.  This adds a large barrier for application
developers wanting to use it in proprietary or dual license models.
Personally, I would much rather see strong adoption than restriction on
use beyond what LGPL provides.

Jason

-----Original Message-----
From: Carsten Hess
Subject: RE: [fdo-internals] Standardising FDO Schema's

Haris,

Well I think the layer is less tightly linked to MapGuide then you might
think. If you look at AutoCAD Map, we have the same API and a lot of
shared code with MapGuide. We sometimes call it the Platform API and use
it within Autodesk to do things similarly as to what you describe. In
fact I keep encouraging people to use these platform API's more and it
is what we build our applications on. You will find the projects files
to create a lean version of the core API's to be part of the mapguide
source stream.


The biggest problem I think is that we would need an open source version
that is an AutoCAD and MapGuide independent implementation of the
resource service and feature service. The other API's including
coordinate system are already pretty independent. We have not done that
yet so it is not free but it is what I would recommend to this group if
we were to entertain the creation of an "FDO application layer" ...

Cheers,
  Carsten


-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris
Kurtagic
Sent: Wednesday, September 03, 2008 8:28 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Standardising FDO Schema's

Carsten,
I think yes, but layer tightly coupled with Mapguide. Some of those
functionalities I see in FDO application layer.

One of things I would like to point out is that in my opinion FDO
providers need to be very light, without extra layers (being too smart,
sorry don't know how to say it in English).

For example, I am thinking to add functionality to FDO KML provider to
allow to write data from different coordinate systems. So you can write
any CS data to KML.
Most probably , right now way to do it is to take some code from MG
feature services ( I hope a lot :) ) and put it inside FDO provider.
That is no way I would like to do it , not even if it is shared library
to use. I would rather do it in "FDO application layer".

Haris

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Carsten Hess
Sent: Wednesday, September 03, 2008 1:49 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Standardising FDO Schema's

Haris,

I wonder ... do you thinkt he MG resource service and feature service
are just that, an application layer on top of FDO? At least that is how
I think of the MG service API's quite often ...