Re: RpgMap: a versatile key/value store for ile rpg

Serialization to binary form is most compact format.
This binary form can also be represented in BASE64, which is less compact,
but you're able for example to copy this text into a mail and send it to
somebody.
Then there is the text format of which i said it's going to look a bit like
JSON.
This text form has the advantage that it's human readable and editable.
Not only maps can be serialized, individual values such as a date can also
be serialized.
This serialization support can then be used to read, for example, a date
from some input that was entered by a user.

So they have different usages:
Binary: most compact and used when it's only being stored/read by the
library.
BASE64: less compact but normal text so you can copy/paste, send via mail,
etc.
Text: human readable/editable.

The text format would look something like:
{ 'date1' : 2017-01-01, 'date2' : 2017-01-02 }

The format isn't determined yet, but if you choose an appropriate format it
automatically looks a bit like JSON.
That it looks like JSON is just some remark i made, just to give an idea.

As for the confusion between JSON and the native format (RMN?) i don't
think that will be a problem.

The binary/BASE64 serialization will also include a (SHA256?) hash to
guarantee integrity.







On Wed, Jul 26, 2017 at 3:28 PM, John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

On Wed, Jul 26, 2017 at 4:06 AM, jacobus erps <jacobus.erps@xxxxxxxxx>
wrote:

The base support for serialization, binary/BASE64 and text, will use

native

formats to represent an RpgMap exactly with its nuances.
Serializing a map and then reading it back again effectively makes a deep
copy.

An external format such as JSON should be a separate project.

OK. So how is the native text format going to "look a lot like JSON",
and how will it look different from JSON? Can you give a sample, or
have you not come up with it yet?

If the native text format isn't going to be a *compatible* superset of
JSON, my suggestion would be to make it very obvious just from looking
at it that it's not JSON. This is to discourage people from trying to
just use standard JSON parsing on it.

Also, you keep referring to the binary serialization as "BASE64". Does
that mean the API won't expose the true binary form, only the
Base64-encoded form? If so, then you are basically saying you'll have
two text serializations, one which is human-readable and one which is
not. This seems odd to me. I don't really see the point of this. But
if you *are* exposing the true binary form, why do you keep tying it
to Base64?

John Y.
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD