[fdo-internals] Vote: FDO RFC 16 - FDO Provider for SQLite

[Jason Birch]

I don't see any problem SDF being "the" reference implementation of FDO
(though it certainly has some deficiencies in this area), and it may be
that SDF could benefit from some of the performance techniques that
Traian is using.  It worries me that a data-agnostic project like FDO
would require that its reference implementation be the fastest or most
widely adopted provider though.  The goals of completeness and
specialization are not always compatible with each other.  I'm guessing
that you've read this:

http://www.databasecolumn.com/2007/09/one-size-fits-all.html

This can easily be extrapolated to spatial data access as well.  A
provider tuned for rapid bounding-box fetches may not necessarily be the
best provider to use for a multi-writer situation.  A provider with a
simple metadata schema may not best reflect the richness of the FDO
schema capabilities.

For me, the new format has a different value proposition than SDF, and I
don't fully accept the argument that if it meets a need that SDF does
not that it will supersede SDF.

I know that performance is Traian's main concern, but what I like most
about this new format is that it is easily adopted by other data access
libraries.  I don't see this same adoption happening with the SDF file
format because it is closely aligned with FDO, is not accessible to the
native SQLite tools, and there is no published specification to work to.
I believe that these interchange points alone are justification for a
new provider / data format.

Jason

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Tuesday, April 01, 2008 11:42
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Vote: FDO RFC 16 - FDO Provider for SQLite

I agree. I would also prefer to see SDF maintained and promoted as the
"official" FDO file format.

Greg

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Badreddine
Karoui
Sent: Tuesday, April 01, 2008 2:25 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Vote: FDO RFC 16 - FDO Provider for SQLite

That's how the SDF provider started: it did simple things realy good and
then it took 3 years to get where it is now. It would probably need a
couple of development(not prototyping) weeks to get it to create SQLite
data.

IMO. We are embarking on an other journey that will eventually create an
other SDF provider. Except, that will be some X years down the road. And
of course, create confusion around the FDO SDF file format.

I'd rather see SDF maintained and promoted as the "official" FDO file
format.

Badreddine

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Tuesday, April 01, 2008 2:02 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Vote: FDO RFC 16 - FDO Provider for SQLite

Survival of the fittest? :)

This is a pretty common situation in open source development.  New
approaches are developed independently without the legacy constraints of
existing solutions, and if the approach is successful the existing
technology either adapts or is superseded.  This allows new ideas to be
explored without disrupting the current code base and requiring
maintenance of backwards-compatibility code for dead-end ideas.

I feel that requiring the simple RFC16 ideas to work within the SDF
framework would slow development and testing of this new approach, and
would require design compromises to meet the current needs of the SDF
provider.  I would be much happier to see the proposed provider put out
there, and the SDF provider react (or not) depending on its adoption.

Jason

-----Original Message-----
From: Greg Boone
Subject: RE: [fdo-internals] Vote: FDO RFC 16 - FDO Provider for SQLite

Well, from my perspective, if we go with this new format then we are in
some manner making a statement that SDF is not sufficient and that this
new provider is intended to be developed as an eventual replacement.
Regardless of the intent right now, that will, in the end, be the
result.
_______________________________________________
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
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals