Network Protocol

[darach]

Signed-off-by: Darach Ennis darach@gmail.com

[mfelsche]

I think if we support publishing, we need to clarify how events originating from a pubsub session are identified in terms of eventid and origin uri. if a publications session is just forwarding events from somewhere else that already have some identifier, we are good. Should we require events to already be identified or do we want to introduce ids and origin uris for pubsub sessions?
This might be a future thing to add.

[darach]

Yes, there's going to be some iteration in the specification here as pipeline and connector endpoints differ significantly and this may move us to a slightly more verbose mapping ( exposing more metadata ). Specifically, tapping into sources and sinks may force handling this more explicitly. As we progress the implementation spike we can true up this draft accordingly

[mfelsche]

Should this be added in the face of Troy being added sooner or later. I could imagine that all we want to expose at some point is a means to issue Troy statements. This could make this protocol spec obsolete. But we can easily evolve into that direction.

[darach]

This is an open question for now. An API proxy simply makes the current API ( REST ) available over messaging. And troy displaces the legacy yaml deployment model with a structured one with better hygienic error handling. We'll need to look into deployment in the context of clustering and deployment, say, via a troy repl and how that relates to API-based deployment changes.