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

Wed Apr 2 04:32:16 EDT 2008

I will say that I agree with Traian, Jason and Frank.
To say that SDF uses SQLite is a simplification.
It uses parts of SQLite to implement a custom spatial database.

Even though the SDF code is Open Source, it is not documented, beyond 
some comments.
It would be great if all GIS would access data, using an FDO provider, 
but that is not going to happen any time soon.

If the SDF is to be a personal spatial database, it will have to come 
with a clean implementation.
Currently, it would require using a tweaked SQLite distribution to get 
SDF support in an application.
That is very difficult to maintain, especially since the changes are not 
documented.

If the official SDF provider is not maintained for whatever reason, I 
would say that it would be very hard for someone outside the core team 
to begin maintaining it.

If you support both a stock SQLite and tweaked SQLite storage format, 
you will need an even more tweaked SQLite library.
Supporting both formats will (IMO) cause confusion, because you cannot 
say "My app supports SDF", because it does not support the tweaked (old) 
version.

While SDF is a nice name and brand, I find it confusing that it shares 
name with the MG 6.5 format, and would find it even more confusing if it 
would also share name with the new format.
I see no problem in SDF being the official FDO/MapGuide format.
The SQLite provider would just be much more interchangeable, and if 
someone decides to use only that format, it is no different than people 
using only Oracle data.

If the SQLite provider turns out to be better than SDF, it would not 
make sense to promote a lesser product, whatever the reasons.
Perhaps the SQLite provider could be renamed SDF in the future, that 
would make the same situation as the MG 6.5 to MG EP upgrade.

Regards, Kenneth, GEOGRAF A/S

Traian Stanev skrev:
> Theoretically, if the SDF provider is modified to support the format exactly as specified in RFC16, for both input and output, there would be no need for a separate provider.
>
> I will be OK with this approach as long as it is guaranteed to adhere to that format. It would be OK to have extra metadata tables as long as they are not required in order for people to make sense out of the data. For example -- no custom encodings for things like Boolean and DateTime, which SQLite does not support. Instead use ISO 8601 for date, for example. A lot more FDO-specific stuff would need to be documented on top of that. There would also be implementation issues, like how to use SQLite column indexes in the SDF query executor, since SDF would not be using the SQLite execution engine. Also, would things like constraints use FDO metadata or SQLite metadata?
>
> So to sum up, in theory I admit that it is possible to make SDF use this format and call it, say SDF4. In practice this will not be easy to do and at the same time stick to both the SDF spirit (superset of all FDO functionality) and the SQLite interchange format (extreme simplicity).
>
>
>
> Traian
>
>
>   
>> -----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 3:43 PM
>> To: FDO Internals Mail List
>> Subject: RE: [fdo-internals] Vote: FDO RFC 16 - FDO Provider for SQLite
>>
>> 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
>> _______________________________________________
>> 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
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20080402/0ac68e20/attachment-0001.html