avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AVRO-341) specify avro transport in spec
Date Sat, 06 Feb 2010 04:49:27 GMT

    [ https://issues.apache.org/jira/browse/AVRO-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830461#action_12830461

Todd Lipcon commented on AVRO-341:

bq. First off, we should probably call this a "protocol"

For the sake of this issue, maybe we discuss "the protocol" vs the "service protocol" or "user
protocol", where the former means the stuff here and the latter means the user-specified .avpr

bq. DISCOVER: Asks the server for information about itself

Does this need to be first-class in the protocol? Rather, can we reserve a namespace of CALLs
that are Avro-scoped? eg org.avro.getServerMetrics(), etc? This seems like it will be less
implementation work since it can share code with the rest of RPC.

Similarly, AUTHENTICATE _could_ be framed as a CALL as well. Though it may be difficult to
integrate SASL here, it's worth exploring.

I think putting all of the request/response through the "call" mechanism will also simplify
some security, request tracing, auditing, etc - it's worth being able to set up a service
such that only authenticated subjects with an "ops" group could see metrics. Or, allow a "nagios"
principal access to the server metrics/health but nothing else.

bq. Or having commands able to include subcommands

Please explain? What's a subcommand?

bq. We need to support out-of-order responses and "one way" (don't wait for a response) commands.

Strongly agree. The "streaming RPCs" (AVRO-406) are another requirement that should fit in
here. To support streaming RPC along with out-of-order response, we should also be able to
_interleave_ response chunks at chunk boundaries.

bq. A simple approach would be to bootstrap it by sending hash(avro protocol schema), and
doing much like we do with calls right now.

So this bootstrap schema would be sent outside the scope of "send things as avro records"?
Or it would just be a bootstrap record that we promise to never ever change except at major
(incompatible) versions?

> 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.

View raw message