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

[Haris Kurtagic]

Jason,

Yes, I think you are right in all points. ( CRS is just one example I
used )
Application layer, I don't think we are inventing anything new, same
principles that already exist for application layers.
It is one entry point for application to work with data/spatial data. 
Functionalities to application layer can be added as wanted.

Perhaps FDO application layer is wrong name.
It is more like Spatial application layer based on FDO.

And also what I think is that one part of entry point to this
application layer doesn't need to be to much different from existing
entry point of FDO provider for basic functionality we have now. That
could allow faster adoption in existing applications.

Some parts of this discussion we already had. There were some not good
experiences from Autodesk, if I am right ?

P.S.
Perhaps better to stop repeating myself in emails, instead should try to
work on some prototype:)

Haris

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Wednesday, September 03, 2008 5:41 PM
To: FDO Internals Mail List; mapguide-internals at lists.osgeo.org
Subject: RE: [fdo-internals] Feature Service application
layer(was:Standardising FDO Schema's)

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