[fpc-pascal] Re: SDFDataset users!?

[michael.vancanneyt at wisa.be]

On Tue, 25 Sep 2012, Reinier Olislagers wrote:

> On 25-9-2012 10:11, michael.vancanneyt at wisa.be wrote:
>> On Tue, 25 Sep 2012, Reinier Olislagers wrote:
>>> On 24-9-2012 18:43, Michael Van Canneyt wrote:
>>> On Mon, 24 Sep 2012, Reinier Olislagers wrote:
>>>>
>>>>> On 24-9-2012 17:22,
>>>>> michael.vancanneyt-0Is9KJ9Sb0A-XMD5yJDbdMReXY1tMh2IBg at public.gmane.org
>>>>> wrote:
>>>>>> On Mon, 24 Sep 2012, Reinier Olislagers wrote:
>>>
>>>>> Finally, I'll post on the forum that sdf compatibility is not one of
>>>>> the
>>>>> goals of sdfdataset.
>>>>>
>>>>> Is there some defined on-disk format that sdfdataset should be
>>>>> following?
>>>>
>>>> As I understood it, it is either fixed length or CSV. CSV as in
>>>> http://tools.ietf.org/html/rfc4180
>>>
>>>
>>> People can only go by what they see (they can't read your mind when you
>>> committed sdfdataset).
> <snip>
>>> All of this makes it in my opinion more likely to be SDF than CSV.
>>
>> Like I said, I had never heard of SDF.
>
> I understand (and appreciate) your reasoning when you committed it.
> Having a CSV dataset is very handy.
>
> Before I understood the full horror of what SDF really means, especially
> as implemented by Delphi (see the nasty behaviour when you add spaces
> after a quoted text and before a delimiter) I thought SDF was really
> some form of CSV, too. (Well I suppose it is, it's just not RFC4180 CSV
> unless you e.g. decide to quote everything. IIRC then it actually
> complies with RFC4180).
>
>> Look, for me, this is not a requirement set in stone, I am quite flexible.
> So am I... see below.
>
>> You guys asked what the original idea was, and I explained some of the
>> history behind the dataset.
> Not really, I asked what the specs were ;)
>
>> If the desire is to have a TSDFDataset (whatever the specs) and a separate
>> CSV dataset, fine, we'll make it so, this is really not a problem.
> Actually, if you are happy with an SDFDataset that complies with RFC4180
> CSV (but not SDF), I would vastly prefer that over the atrocity that is
> SDF - as long as this requirement/behaviour is quite clearly specified
> (e.g. in a readme).

No problem :-)

>
> If you think that any changes to sdfdataset to make it RFC4180 compliant
> are acceptable to current users, fine by me ;)

I have not seen any evidence that it has ever been used other than for CSV,
but I may be wrong. So I suspect that this should be acceptable.

>
> The csvdocument [1] code has a very nice record-by-record CSV parser and
> writer with test set that aims to be RFC4180; this could be used for
> interoperability testing or even, if evidence by test set failures, used
> instead of parts of the current code.

I'm fine with that.

>
>> I don't want anyone to feel that he has wasted his time :-)
> Well, getting clarity about what the on disk format must be is worth it
> even though I can't really say I enjoyed this particular episode :)
> Even better, as I said, if everybody is happy with RFC4180 CSV, I vastly
> prefer that format to SDF and would consider my time well spent.
>
> I'm sure tatamata from the forum will appreciate it too (AFAIR, his
> ZMSQL is based on sdfdataset).
>
> I'm just not interested right now in implementing either a test set or
> the changes myself, but perhaps somebody else is.

Well, in the not-too-far future, I'll spend time on improving the DB testsuite.

Michael.