DynamicSerialization - just for values or also messages?

[havocp]

The doc comment says SbtClient.dynamicSerialization is for values AND messages. But right now it doesn't look like that's true (the Message trait is sealed and we never look up message Format in dynamicSerialization).

One fix could be:

• rename SbtClient.dynamicSerialization to valueSerialization or even buildValueSerialization to clarify
• doc it as task values only
• add CustomEvent(name: String, payload: JsValue) extends Event, where name is the type name we send on the wire and use to find the serializer and payload is everything else from the JsValue
• whenever we can't deserialize an event, deserialize as CustomEvent
• right now UIContext doesn't support request/reply so we don't need custom versions of those
• when writing out events people just supply the serializer statically
• when receiving events people can just switch on type name and then apply a static deserializer. Or in activator's case, probably just pass through to JS with no registration of deserializers in Scala - we want plugins to be an sbt plugin and a JS plugin with no changes to Scala part of activator
• we could add a messageDeserialization registry to SbtClient later but if we did it'd just remap CustomEvent when it recognized the type name. So just a convenience thing.

Just an initial sketch, not sure how it will play out.

[havocp]

Just saw we have sendRawEvent on UIContext which uses dynamic serialization. In my proposal I'd suggest we delete this. Why would I have access to T but not Writes[T] if I am an sbt plugin working with T and UIContext? I should have the Writes[T].

Values are different because they are sent generically by the task engine, rather than sent by the task itself. The task itself sends events and knows the type statically so can just provide a Writes.

[havocp]

Another aspect of this is https://github.com/sbt/sbt-remote-control/issues/167 - just looked through Protocol.scala and none of the current messages are OK for a plugin or task to send. They are all only for the sbt server engine to send. So CustomEvent really is just TaskEvent or something like that - and task events should probably have their whole own namespace. Sending ExecutionStarted from a task should make a TaskEvent(ExecutionStarted) not a toplevel ExecutionStarted.