<div dir="ltr"><div><div dir="ltr">On Mon, Mar 22, 2021 at 12:08 PM Loïc Hoguin <<a href="mailto:lhoguin@vmware.com">lhoguin@vmware.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
Currently the Erlang Term Format has two variants:<br>
<br>
 * the full featured format that includes different forms of atom caches<br>
<br>
 * the simpler term_to_binary/1 format that does not<br>
<br>
This is not a satisfying state of affairs: sometimes we want to use<br>
term_to_binary/1 for protocols or when exchanging data, but the lack<br>
of atom cache can result in us sending a lot of 'undefined' atoms in<br>
string form.<br>
<br>
  => Should term_to_binary/1 allow setting up an atom cache?<br>
     Perhaps the cache could be maintained as a map to be encoded<br>
     separately by the user. This could also allow predefining<br>
     the most common atoms that could then never be sent (for<br>
     example #{undefined => 1, true => 2, false => 3}). Whatever<br>
     the interface we should reuse as much of the distribution<br>
     header atom cache code as possible.<br>
<br>
An alternative would be to build our own format loosely based on the<br>
Erlang Term Format. But in that scenario we end up lacking at least<br>
the pid_info/1 and ref_info/1 functions that would allow us to encode<br>
a pid/reference without having to use either term_to_binary/1 or<br>
{pid,ref}_to_list/1. On the other side the pid/reference can be<br>
recomposed via a pid_from_info/1 or ref_from_info/1 type of function.<br>
<br>
These functions can be useful to have regardless of the answer to the<br>
first question above. For example pid_info/1 is used in Mnesia here:<br>
<br>
 <a href="https://github.com/erlang/otp/blob/master/lib/mnesia/src/mnesia_locker.erl#L1270" rel="noreferrer" target="_blank">https://github.com/erlang/otp/blob/master/lib/mnesia/src/mnesia_locker.erl#L1270</a><br>
<br>
And also in RabbitMQ here, as well as pid_from_info/1:<br>
<br>
 <a href="https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit/src/pid_recomposition.erl" rel="noreferrer" target="_blank">https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit/src/pid_recomposition.erl</a><br>
<br>
I've also been writing similar code when experimenting with custom<br>
distribution drivers.<br>
<br>
  => Should erlang:pid_info/1 and erlang:pid_from_info/1 be added?<br>
     This is the strongest case as there's code in the wild<br>
     already doing this.<br>
<br>
  => Should erlang:ref_info/1 and erlang:ref_from_info/1 be added?<br>
<br>
It's possible that ports and funs may benefit as well, but I have<br>
a hard time figuring out when we would want to use a port that<br>
way, and funs I believe that we already have everything we need<br>
as long as they're not anonymous funs.<br>
<br>
Cheers,<br>
<br>
-- <br>
Loïc Hoguin<br>
<br>
</blockquote></div><br clear="all"></div><div>It is a bit unfortunate that the "creation" value of the node part is so well hidden since the full identifier of a node is its nodename together with its creation. It would have been nice if the node/1 BIF had returned '{Nodename, Creation}' instead of just 'Nodename', but that is too late to change now. Perhaps a nid/1 BIF?</div><div><br></div><div>Currently pids, ports and references are the datatypes that contain node identifiers which also are the types the node/0 BIF can handle.<br></div><div><br></div><div>I think it is reasonable with functionality for creation of such data types from full information, so that alternative protocols wont have to go via the external term format.<br></div><div><br></div><div>Regards,</div><div>Rickard<br></div><div>-- <br><div dir="ltr" class="gmail_signature">Rickard Green, Erlang/OTP, Ericsson AB</div></div></div>