×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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.
As an Amazon Associate we earn from qualifying purchases.