[fpc-devel] Rather large flaw in TJSONConfig component

[Michael Van Canneyt]

On Tue, 22 Jun 2010, Graeme Geldenhuys wrote:

> Op 2010-06-21 17:11, Michael Van Canneyt het geskryf:
>>
>> Only if you program it so. I program with UpdateMode=upWhereKeyOnly, and
>> then all updates go through, unless the record was deleted.
>>
>>> Because they don't get notified about their data (last saved) being lost. :-)
>>
>> Well, I prefer that over bugging our users with dialogs that they don't understand
>> anyway. Additionally, it drastically degrades performance.
>
> [getting a bit off-topic here]
>
> That is a rather dangerous approach to take. Imagine two accountants have a
> Clients transaction screen open - both adding new transactions. First
> accountant processes a 1 million Euro purchase. Then the second accountant
> processes a 50 Euro purchase. Using your thinking, that Client will now
> only owe use 50 euros. :-(

Well, we actually have such an application (bookkeeping app).

And: 
1. No the error will not occur, since they are processing different transactions
    and therefor different 'documents'.
2. The balance is always calculated on-demand; not stored.

> We handle concurrency slightly different. We use System Locks. The first
> person in a area get the system lock. Anybody else afterwards only sees
> that area as read-only with a option to send a message to the first user to
> get out of that area if it is urgent.

We have a lock on the 'document' level. Only one person can edit a document
at a time. The second gets a message.

>
>
>> You can start documenting them if you wish. But they won't be included
>> in the official docs till fully finished.
>
> That's what I asked, and I'm fine with that. :-)
>
>
>> (Actually, I started on fcl-json
>> to get it included on www.json.org. Documentation is a prerequisite)
>
> I saw the message you forwarded from json.org - a reasonable prerequisite.

But with large consequences, given our time constraints :-)

> I'm looking a bit more into JSON - it's a rather nice format. Easy to read
> (human readable) and differentiates nicely between arrays, integer, object
> and string types (describing data types) - much better than XML does.
>
> eg:
> <person name="john" age="28">
> </person>
>
> vs
>
> { "person": {
>      "name": "john",
>      "age": 28
>   }
> }
>
> The JSON output immediately tells me that name is a text field and age is
> an integer field. It's not obvious in the XML where all attribute values
> must be enclosed in quotes.

For small config needs, I think that JSON is a better choice. It's
leight-weight, which is also the very reason it was invented: to counter all
SOAP XML bloat.

Well, FPC makes using/handling json particularly easy. Even if I do say so myself ;-)
A warning: FPC currently has only ansistring support for JSON. I didn't get
around to making it unicode-aware (as the standard actually dictates). But
with the new string type, this should be a no-brainer :-)

Michael.