[
https://issues.apache.org/jira/browse/AVRO-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12832612#action_12832612
]
Philip Zeyliger commented on AVRO-341:
--------------------------------------
{quote}
> I'd like us to consider describing Avro's protocol in terms of (and here the
> terminology falls down) an Avro protocol, or at least in terms of Avro
> records.
I think this could be deceptive if we don't support Avro versioning features
here. I think it's often simpler to bootstrap a system not using itself but
using a more primitive system. We'd like the transport to be extensible. Many
protocols use a combination of named commands, key/value meta-data and a binary
payload to provide extensibility. A description at this level in Avro is
possible, but would probably not be able to describe the internal structure of
every command's payload. So, in practice, folks might not in fact implement a
so-specified transport using Avro, as that might require an extra copy of
payload data. So we might stick to using Avro to describe just the
command+metadata part, and leave payloads outside of this. Or we might
alternately describe the command+metadata part as something as simple as
<command>(<newline><name><colon><value><newline>)*<newline><payload>.
{quote}
bq. I think this could be deceptive if we don't support Avro versioning
features here
I think we have to find a way to bootstrap RPC so that we *do* support Avro's
versioning features on the Avro Rpc Protocol. We're going to want to add
things like introspection. The good news is that the bootstrap can be dead
simple: we could explicitly version the schemas that servers and clients
understand. (With the restriction that versions still have to be forwards and
backwards compatible in the Avro sense, but we can force the sender to project
back into the older version.) Or we could do something more complicated and
exchange the schemas like the current transport does.
bq. as that might require an extra copy of payload data.
If we have to copy bytes, that indicates mostly a limited API, and not a
fundamental restriction. Our users will implement things where they wish to
avoid byte copying too, so this is as good a use case as any to see if we can
pull it away. For this reason, I'm "meh" on the proposal of separating control
and data planes, though it might be the simplest way around Avro bytes not
being framed.
I think we've got enough information in this thread that we should probably all
hash it out in front of a whiteboard.
> specify avro transport in spec
> ------------------------------
>
> Key: AVRO-341
> URL: https://issues.apache.org/jira/browse/AVRO-341
> Project: Avro
> Issue Type: Improvement
> Components: spec
> Reporter: Doug Cutting
>
> We should develop a high-performance, secure, transport for Avro. This
> should be named with avro: uris.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
