RFC: std.json sucessor

via Digitalmars-d digitalmars-d at puremagic.com
Mon Aug 25 12:20:56 PDT 2014


On Monday, 25 August 2014 at 15:46:12 UTC, Ola Fosheim Grøstad 
wrote:
> For a web server it would be most useful to get an exception 
> since you risk ending up with web-clients not working with no 
> logging. It is better to have an exception and log an error so 
> the problem can be fixed.

Let me expand a bit on the difference between web clients and 
servers, assuming D is used on the server:

* Web servers have to check all input and log illegal activity. 
It is either a bug or an attack.

* Web clients don't have to check input from the server (at most 
a crypto check) and should not do double work if servers validate 
anyway.

* Web servers detect errors and send the error as a response to 
the client that displays it as a warning to the user. This is the 
uncommon case so you don't want to burden the client with it.

 From this we can infer:

- It makes more sense for ECMAScript to turn illegal values into 
null since it runs on the client.

- The server needs efficient validation of input so that it can 
have faster response.

- The more integration of validation of typedness you can have in 
the parser, the better.


Thus it would be an advantage to be able to configure the 
validation done in the parser (through template mechanisms):


1. On write: throw exception on all illegal values or values that 
cannot be represented in the format. If the values are illegal 
then the client should not receive it. It could cause legal 
problems (like wrong prices).


2. On read: add the ability to configure the validation of 
typedness on many parameters:

- no nulls, no dicts, only nesting arrays etc

- predetermined key-values and automatic mapping to structs on 
exact match.

- require all leaf arrays to be uniform (array of strings, array 
of numbers)

- match a predefined grammar

etc




More information about the Digitalmars-d mailing list