Closed danielballan closed 5 years ago
I like serialize, followed by pack, then export, then saveas
:-1: on dump and save
Personally I think something like ‘serialize’ will result in being asked “why didn’t you use a term that is more generally known”. The average user won’t recognize what it means, but something like ‘export’ or ‘save’ will be more generally understood.
Serialize/dump sound more explicit, but I think they're also subjective in directionality. I thought of "list of DB dicts" as more serialized than a .tiff file. Export sounds like you're leaving the DB environment.
Can you give examples where "export" is misleading?
I volunteer something like "to_docs" or "from_docs"; its less conventional, but explicitly directional.
Are we missing an obvious one here: “write”? That is the method typically using under the hood. I still prefer “serialize” as the most accurate term for this, but prefer “write” to export or the other alternatives.
We also might want a more descriptive term for what we have called “wrappers”, and “writers” for this isn’t bad.
This has been partially resolved with PR #1. The latest commits introduces a serializer
class that creates an object that takes in (name, doc) pairs and serializes them using a defined Manager
(previously called wrapper
). It then also has an export
method that takes in a stream of (name, doc) pairs and feeds them through the serializer.
Of course we can change these names if we decide on new ones but this appears to cover all of the naming issues we discussed above.
I volunteer something like "to_docs" or "from_docs"; its less conventional, but explicitly directional.
but if it is going into mongo, it is going to docs both ways!
Can you give examples where "export" is misleading?
Having sat with this for a bit, I'm not sure I can. I am pretty happy with the two-layer system we have been building out in our suitcase-tiff prototype, with a user-facing, pull-based "take my data home" function named export
and a separate, lower-level, push-based component where the brains live. For that lower-level compoent, I think Serializer
is appropriate. Per Wikipedia the directionality of "serialize" is well-defined, though the point is well-taken that it may not be widely known to physical scientists so it's best kept below the "top layer".
[I]n the context of data storage, serialization...is the process of translating data structures or object state into a format that can be stored (for example, in a file or memory buffer) or transmitted (for example, across a network connection link) and reconstructed later (possibly in a different computer environment). ... The opposite operation, extracting a data structure from a series of bytes, is deserialization.
If no one expresses strong opposition to export
+ Serializer
then I expect that is where suitcase-tiff
and following suitcases will land.
+1 for export
+ serializer
I still like pack
+ serializer
but acknowledge that is probably too cute by half.
I think "pack" is cute too but I think "export" has the momentum at this point.
@stuartcampbell points out that 'export' could be confusing if you are on the "receive" side of the pipe. For the user exporting files it's clear, and as @awalter-bnl says at least all exporters share the same direction, but can we do better?
h/t @mrakitin for some ideas here