[
https://issues.apache.org/jira/browse/AVRO-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830464#action_12830464
]
Philip Zeyliger commented on AVRO-341:
--------------------------------------
bq. 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.
We definitely need to put in a little bit more thought in how a server can be
servicing many Avro "user protocols" simultaneously, which would allow it,
then. Then you might be able to say "hey, also serve the following built-in
services".
But then how do you discover whether those services are being served? I guess
you could call them, and get a MethodNotFound/Supported error.
bq. AUTHENTICATE could be framed as a CALL as well. Though it may be difficult
to integrate SASL here, it's worth exploring.
I'd draw the line here, though. I think the "user protocol" has things to do
with the service being offered, but there are commands that affect the state of
the server in a way the client shouldn't be aware of. AUTHENTICATE is one.
"SET_COMPRESSION_LEVEL" might be another. These affect how the server behaves
for this connection in a way that's transparent to the "user protocol"
implementor.
bq. [bootstrapping]
Yes, we'd try never to change it? What, you don't believe me?
> 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.
