Hi Przemek,
>> >JSON format does not support dates and timestamp values.
>> >So when you pass date item to be converted to JSON format
>> >we have 3 choices:
>> >1. generate RTE
>> >2. convert date to some other format, accepted by JSON, i.e.
>> > "YYYYMMDD" strings
>> >3. store it as NIL/NULL value.
>> We could also consider a 4th choice, I.e. when converting date to
>> string in the wrapper add extra flag to the string such that when it
>> is decoded the wrapper will again convert the JSON decoded string to
>> a date value. This of course means that the string coded by JSON
>> will read something like:
>> {DATE}YYYYMMDD
>> and it will therefore not be usable by other JSON decoders unless
>> they expect such convention.
>
> This is not such simple. It cannot be implemented cleanly.
> JSON is very strict format. Adding rule to deserialize procedure
> that strings in format:
> [{]DATE[}][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]
> are decoded as dates causes that it's not possible to pass such
> string because it will be converted to date during decoding, i.e.
> it's not possible to divide this message into words in an array and
> then encode and decode it using such hacked JSON decode algorithm.
> The result will be different then the source though source contains
> perfectly valid JSON data. So adding such hack to handle date values
> which are unsupported by JSON breaks decoding supported data.
> The only one way to handle new types automatically is adding some
> new type to JSON format which will not interact with existing ones.
> Anyhow JSON is very simple format for validators and it's very easy
> to write simple state machine which will be perfectly restrictive in
> format checking so you should expect that any "local" extensions will
> be detected immediately by foreign systems and decoding refused.
> This is one of the most important JSON features which makes it popular
> to exchange data between different systems. It has only small set of
> supported data types stored in very simple format which can be easy
> validated by decoding procedure so any local hacks or bugs in
> implementation are easy to detect.
> BTW Mindaugas didn't implement such state machine but only simple
> decoding algorithm which assumes that input data is correct. It's
> acceptable though state machine could also improve decoding speed
> so we may thing about adding it in the future.
I Was not talking about the actual JSON encoder/decoder, I actually assumed
that Mindaugas only provided PRG wrappers, and the hack I was considering is
only at the PRG WRAPPER level. IOW the NATIVE JSON encoder will not be
modified in any way, it will receive a simple string to encode and the
resulting encoded data should be perfectly valid to any valid JSON decoder,
regardless of its implementation.
Of course the issue of possible conflict with real such string can be easily
removed (for all practical applications) f.e.:
{JSON.TYPE.EXTENSION.DATE:YYYYMMDD}
Naturally the possibility that someone will want to stream such real string
is only theoretical .
Obviously any and all valid decoders will simply decode the date into the
above literal string, and no harm should be present.
Ron
------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________
xHarbour-developers mailing list
xHarbour-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xharbour-developers
