<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I will say that I agree with Traian, Jason and Frank.<br>
To say that SDF uses SQLite is a simplification. <br>
It uses parts of SQLite to implement a custom spatial database.<br>
<br>
Even though the SDF code is Open Source, it is not documented, beyond
some comments.<br>
It would be great if all GIS would access data, using an FDO provider,
but that is not going to happen any time soon.<br>
<br>
If the SDF is to be a personal spatial database, it will have to come
with a clean implementation.<br>
Currently, it would require using a tweaked SQLite distribution to get
SDF support in an application.<br>
That is very difficult to maintain, especially since the changes are
not documented.<br>
<br>
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.<br>
<br>
If you support both a stock SQLite and tweaked SQLite storage format,
you will need an even more tweaked SQLite library.<br>
Supporting both formats will (IMO) cause confusion, because you cannot
say "My app supports SDF", because it does not support the tweaked
(old) version.<br>
<br>
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.<br>
I see no problem in SDF being the official FDO/MapGuide format. <br>
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.<br>
<br>
If the SQLite provider turns out to be better than SDF, it would not
make sense to promote a lesser product, whatever the reasons.<br>
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.<br>
<pre class="moz-signature" cols="72">Regards, Kenneth, GEOGRAF A/S
</pre>
<br>
<br>
Traian Stanev skrev:
<blockquote
cite="mid:D20FC5C02CA4AB41891CFE76D91C57A925300D6A0D@ADSK-NAMSG-02.MGDADSK.autodesk.com"
type="cite">
<pre wrap="">
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
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a> [<a class="moz-txt-link-freetext" href="mailto:fdo-internals">mailto:fdo-internals</a>-
<a class="moz-txt-link-abbreviated" href="mailto:bounces@lists.osgeo.org">bounces@lists.osgeo.org</a>] 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:
<a class="moz-txt-link-freetext" href="http://www.databasecolumn.com/2007/09/one-size-fits-all.html">http://www.databasecolumn.com/2007/09/one-size-fits-all.html</a>
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: <a class="moz-txt-link-abbreviated" href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>
[<a class="moz-txt-link-freetext" href="mailto:fdo-internals-bounces@lists.osgeo.org">mailto:fdo-internals-bounces@lists.osgeo.org</a>] 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: <a class="moz-txt-link-abbreviated" href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>
[<a class="moz-txt-link-freetext" href="mailto:fdo-internals-bounces@lists.osgeo.org">mailto:fdo-internals-bounces@lists.osgeo.org</a>] 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: <a class="moz-txt-link-abbreviated" href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>
[<a class="moz-txt-link-freetext" href="mailto:fdo-internals-bounces@lists.osgeo.org">mailto:fdo-internals-bounces@lists.osgeo.org</a>] 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
<a class="moz-txt-link-abbreviated" href="mailto:fdo-internals@lists.osgeo.org">fdo-internals@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/fdo-internals">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a>
_______________________________________________
fdo-internals mailing list
<a class="moz-txt-link-abbreviated" href="mailto:fdo-internals@lists.osgeo.org">fdo-internals@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/fdo-internals">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a>
_______________________________________________
fdo-internals mailing list
<a class="moz-txt-link-abbreviated" href="mailto:fdo-internals@lists.osgeo.org">fdo-internals@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/fdo-internals">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a>
_______________________________________________
fdo-internals mailing list
<a class="moz-txt-link-abbreviated" href="mailto:fdo-internals@lists.osgeo.org">fdo-internals@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/fdo-internals">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a>
</pre>
</blockquote>
<pre wrap=""><!---->_______________________________________________
fdo-internals mailing list
<a class="moz-txt-link-abbreviated" href="mailto:fdo-internals@lists.osgeo.org">fdo-internals@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/fdo-internals">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a>
</pre>
</blockquote>
</body>
</html>