search

williamthome / euneus

An incredibly flexible and performant JSON parser, generator and formatter in pure Erlang.
https://hex.pm/packages/euneus
Apache License 2.0
22 stars 2 forks source link

Decoding/Encoding processes IDs and ports #25

Closed vkatsuba closed 9 months ago

vkatsuba commented 9 months ago

Hi! Great library! It looks like current lib cannot encode/decode processes IDs and ports. This is one of reasons why some projects want use jsone instead of 'jsx`.

Best Regards, --V

williamthome commented 9 months ago

Hi, @vkatsuba! This should be a nice plus to Euneus. I'll take a look on how to decode them and come back with a response. Thanks for this issue!

williamthome commented 9 months ago

Encoding any value is easy, the problem is to decode them back to their original state. I described about this here in the README.

I'm thinking of implementing a plugin mechanism for types that it's not easy to decode to not hurt performance encoding and decoding "common" JSON types, e.g.:

#{ plugins => [euneus_port_plugin, euneus_pid_plugin, euneus_inet_plugin] }

These plugins should have an euneus_plugin behavior. In this way, these types are optional and are not handled to not decrease the performance when you don't need them.

@vkatsuba, what's your opinion/suggestion about this?

vkatsuba commented 9 months ago

I suppose the main point here is provide encoding as a first part. Encoding PIDs, Ports, functions, records, terms - why it need? It useful for case well if somebody want to store it as text data in disk or provide it to UI as a simple text data. It also related to tuples which has no similar or related data to JSON like - type with 1 or 4 elements etc. Decoding back - here we have then other question.. should we try decode it back or just keep it as list or binary? Well at least because this value can provided a simple text right? {"hello", "{\"wold\": true}"} can expected as a text. So, first step will be focus on encoding part, then it will more clear to see - how it should works for decoding - maybe as you mention - for decode specific values need provide specific parameters like - decode to Erlang terms or something like that - then developer will suggest how it should looks after decoding.

williamthome commented 9 months ago

What I see for types not implemented in Euneus is they are for specific use cases or user custom types.

This PR implements what I said about plugins. Using this mechanism any "custom" types are easy to handle, and having them built-in is possible and the use is optional. I'll be happy with your feedback about it :slightly_smiling_face:

@eproxus has suggested something similar to the plugins mechanism for Thoas here.