Hyperion icon indicating copy to clipboard operation
Hyperion copied to clipboard

Documentation

Open aienabled opened this issue 8 years ago • 4 comments

Hi guys, the job done with Wire/Hyperion is impressive! But it's not very useful if developers like me cannot quickly become familiar with the technology. The developers community need to have a documentation, API reference, wiki, samples, developers blog (who've decided to call it Hyperion and why? :) very interesting!)... but currently we have only a very brief readme file!

In my particular interest:

  • Are the attributes required to mark the serializable types or there are available any alternative ways to register the types for serialization? I have a use case when it's not possible to explicitly mark the types as serializable, so Reflection must be used to specify which types (and fields) are will be serialized by Hyperion.
  • I've seen a test case for the circular references handling... so, does Hyperion have full support of the references serialization? Are there any known limitations?
  • Are there any support for long-time "serialization sessions" - in a such way, that when it's provided to the serialization/deserialization methods the previously serialized object will be not serialized fully next time (only the reference will be written) when we serialize something containing a reference to that object? (use case - sending delta-updates to connected clients when some data changes. The delta-update might contain an already sent object - so the references should be preserved instead of creating the new instances)
  • Is it possible to have a conditional surrogate (in a such way that the surrogate itself will decide if the object will be "surrogated" or not (serialized as without the surrogate))?

Currently we're using https://github.com/AqlaSolutions/AqlaSerializer (based on protobuf-net, but provides full support for the object references serialization) for our serialization needs, it satisfies all the requirements, but we're looking for something more reliable, clean and rapidly developing.

Regards!

aienabled avatar Jan 09 '17 12:01 aienabled

Hi @aienabled :

  • There are no attributes necessary. Serializer will build an object reader/writer pair first time it'll see a data of target type to be serialized/deserializer. You can supply it up front by providing a SerializerOptions(knownTypes: new Type[0]) with array of types, that you know, will be used.
  • Object references can be preserved by using SerializerOptions(preserveObjectReferences: true). By default this option is set to false.
  • I'm not sure yet, but this could be potentially possible by building a SerializerSession/DeserializerSession up front, and provide it (it's optional param) to Serialize/Deserialize methods.
  • No, there are no conditional surrogates. They could probably be implement within usual surrogate logic, but I'd need to see which parts of existing API could be used for that or need to be exposed.

Horusiath avatar Jan 09 '17 15:01 Horusiath

woohoo someone else interested in documentation ;) :)

sean-gilliam avatar Jan 09 '17 16:01 sean-gilliam

Hello @Horusiath ,

I would like to see more documentation. I might use Hyperion als serializer in an Akka persistence scenario. The Akka.Net documentation links to Hyperion on GitHub. Under "Version tolerance" three modes of operation are described. But is doesn't say how I can configure which mode to use (either in code or in HOCON.

gfgw avatar Mar 06 '18 16:03 gfgw

@gfgw At this point in time version tolerance is not finished in Hyperion (the information about fields is carried with a payload for future use, but not yet used on deserializer side). We also heavily discourage using it in persistence scenarios - simply because it's still in beta, and its binary format will very likely change in the future.

Horusiath avatar Mar 07 '18 07:03 Horusiath