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

[Jason Birch]

Haris,

Apart from CRS handling, how do you see this application layer working?
Would all applications connect to this middle tier that then manages
access to the individual providers?  If so, I could see this being a
good place for "levelling" functionality, or a base functionality.  I
believe that MapGuide is doing this already for things like statistical
interval calculations for theming, etc.

If some effort was put into this layer, it could provide a default
implementation of things like expressions, sorting, results paging, and
other basic functionality that could then be overridden by individual
providers when it makes sense to do so.  This would ensure that all
providers had basic functionality even if it was not performant,
reducing the amount of capabilities checking that application developers
have to do, and avoiding the LCD effect (only implementing common
functionality) in independent applications.

Jason

-----Original Message-----
From: Jason Birch
Subject: [fdo-internals] Feature Service application layer
(was:Standardising FDO Schema's)

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 ...
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals