Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serializer Configuration [proposed Label] feature #61

Open
pgaref opened this issue Feb 11, 2016 · 3 comments
Open

Serializer Configuration [proposed Label] feature #61

pgaref opened this issue Feb 11, 2016 · 3 comments

Comments

@pgaref
Copy link
Contributor

pgaref commented Feb 11, 2016

Currently supported SEEP serializers are:

  • Java (default)
  • Kryo
  • Avro

First in the TODO list is the user to be able to select the preferred serializer. For this reason, we need to add extra configuration option in the MasterConfig and WorkerConfig - we also need to check those two are consistent when workers connect to the master(?)

Second: when users implement custom classes for the queries there should be an easy way to register those classes to the serializer. Currently those classes should be part of the seep-common project in order to be serializable by both the master and the workers. Which is the easiest way to do that?

@raulcf
Copy link
Owner

raulcf commented Mar 10, 2016

Sounds good. However, I'd reduce the priority of this until there is a use case that requires a specific serializer. Do you have one already?

@pgaref
Copy link
Contributor Author

pgaref commented Mar 10, 2016

I have done some progress in a local branch but nothing complete - I was also wondering if the same serializers should be used for sending SeepCommands over network or keee using Kryo for that..(maybe this makes things more complicated since the nodes should know which serialiser to use beforehand - to send the bootstrap command)
I totally agree with the priority - its not urgent.

@raulcf
Copy link
Owner

raulcf commented Mar 10, 2016

right, it should only be implemented under demand. Once someone has a good use case for this. I left this in the code to show the flexibility and open that door.
thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants