Problem: sometimes, ProcessUniqueId internals access is needed

[yrashk]

For example, for serialization

Solution: expose fields as public ones

[Stebalien]

Hm, I'll have to think about this. Serializing ProcessUniqueIDs can be dangerous given that they're only guaranteed to be unique within a process for the life of the process. However, to be useful for RPC/inter process communication, they need to be serializable.

One solution would be to map the prefix to a UUID as needed:

• When serializing, lookup the prefix in a UUID/prefix map, generating a new UUID if not present. Seralize the ID as (UUID, offset).
• When deserializing, lookup the serialized UUID in the UUID/prefix map, choosing a new prefix if not present. Deserialize as (UUID, offset).

Although I guess they would no longer be "process unique".

If I don't get back to you within a few days, please bug me.

[yrashk]

Actually, in my case them being process unique is fine, they only serve as random identifiers that are always handled by the same process (which has a map associating these ids with resources) https://github.com/PumpkinDB/PumpkinDB/blob/master/src/script/storage.rs#L60

[Stebalien]

What's your use-case for serializing? I'd prefer to, e.g., implement Serialize using serde instead of exposing internals directly so I remain free to change them (for example, to implement #3).

I am worried that users will accidentally abuse serialization (e.g., derive Serialize for a struct that contains a ProcessUniqueID and persist it somewhere); However, I guess that's probably just paranoid.

[yrashk]

Steven, sorry for this huge delay. Serializing without exposing details would be totally cool for me. All I need is a compact binary representation of the ID — don't care what's inside.

[Stebalien]

Sorry for the even longer delay...

I've merged #8 which implements serialization through serde.