laurentgo commented on code in PR #34817:
URL: https://github.com/apache/arrow/pull/34817#discussion_r1423045013
##########
format/Flight.proto:
##########
@@ -525,3 +525,108 @@ message FlightData {
message PutResult {
bytes app_metadata = 1;
}
+
+/*
+ * EXPERIMENTAL: Union of possible value types for a Session Option to be set
to.
+ */
+message SessionOptionValue {
+ message StringListValue {
+ repeated string values = 1;
+ }
+
+ oneof option_value {
+ string string_value = 1;
+ bool bool_value = 2;
+ sfixed32 int32_value = 3;
+ sfixed64 int64_value = 4;
+ float float_value = 5;
+ double double_value = 6;
+ StringListValue string_list_value = 7;
+ }
+}
+
+/*
+ * EXPERIMENTAL: A request to set session options for an existing or new
(implicit)
+ * server session.
+ *
+ * Sessions are persisted and referenced via RFC 6265 HTTP cookies, canonically
+ * 'arrow_flight_session_id', although implementations may freely choose their
own name.
+ */
+message SetSessionOptionsRequest {
+ map<string, SessionOptionValue> session_options = 1;
+}
+
+/*
+ * EXPERIMENTAL: The results (individually) of setting a set of session
options.
+ */
+message SetSessionOptionsResult {
+ enum Status {
+ // The status of setting the option is unknown. Servers should avoid using
+ // this value (send a NOT_FOUND error if the requested query is
+ // not known). Clients can retry the request.
+ SET_SESSION_OPTION_RESULT_UNSPECIFIED = 0;
+ // The session option setting completed successfully.
+ SET_SESSION_OPTION_RESULT_OK = 1;
+ // The given session option name was an alias for another option name.
+ SET_SESSION_OPTION_RESULT_OK_MAPPED = 2;
+ // The given session option name is invalid.
+ SET_SESSION_OPTION_RESULT_INVALID_NAME = 3;
+ // The session option value is invalid.
+ SET_SESSION_OPTION_RESULT_INVALID_VALUE = 4;
+ // The session option cannot be set.
+ SET_SESSION_OPTION_RESULT_ERROR = 5;
+ }
+
+ message Result {
+ Status status = 1;
+ }
+
+ map<string, Result> results = 1;
+}
+
+/*
+ * EXPERIMENTAL: A request to access the session options for the current
server session.
+ *
+ * The existing session is referenced via a cookie header; it is an error to
make this
+ * request with a missing, invalid, or expired session cookie header.
+ */
+message GetSessionOptionsRequest {
+}
+
+/*
+ * EXPERIMENTAL: The result containing the current server session options.
+ */
+message GetSessionOptionsResult {
+ map<string, SessionOptionValue> session_options = 1;
+}
+
+/*
+ * Request message for the "Close Session" action.
+ *
+ * The exiting session is referenced via a cookie header.
+ */
+message CloseSessionRequest {
+}
+
+/*
+ * The result of closing a session.
+ */
+message CloseSessionResult {
+ enum Status {
+ // The session close status is unknown. Servers should avoid using
+ // this value (send a NOT_FOUND error if the requested session is
+ // not known). Clients can retry the request.
+ CLOSE_RESULT_UNSPECIFIED = 0;
+ // The session close request is complete. Subsequent requests with
+ // the same session produce a NOT_FOUND error.
+ CLOSE_RESULT_CLOSED = 1;
+ // The session close request is in progress. The client may retry
+ // the close request.
+ CLOSE_RESULT_CLOSING = 2;
+ // The session is not closeable. The client should not retry the
Review Comment:
I kind of agree with @pitrou . Client may not be interested and/or forgot to
close the session, or a network or a backend issue may happen which may cause
the session not to be closed proactively, so I would also adopt a best effort
approach where the client may notify the server the session is to be closed,
and the server will do its best to honor the request?
I would also be hesitant of tightening them to auth session instead of
keeping separate as they may different lifecycle and TTLs
##########
format/Flight.proto:
##########
@@ -525,3 +525,108 @@ message FlightData {
message PutResult {
bytes app_metadata = 1;
}
+
+/*
+ * EXPERIMENTAL: Union of possible value types for a Session Option to be set
to.
+ */
+message SessionOptionValue {
+ message StringListValue {
+ repeated string values = 1;
+ }
+
+ oneof option_value {
+ string string_value = 1;
+ bool bool_value = 2;
+ sfixed32 int32_value = 3;
+ sfixed64 int64_value = 4;
+ float float_value = 5;
+ double double_value = 6;
Review Comment:
I wonder about the strong typing and how it would actually be used between a
client and server without having both of them know in advance what the type is?
In the context of URL parsing, if we allow for passing extra options as
query parameters, all of them would be untyped so how the client would be able
to provide them to the server with the correct type?
##########
format/Flight.proto:
##########
@@ -525,3 +525,108 @@ message FlightData {
message PutResult {
bytes app_metadata = 1;
}
+
+/*
+ * EXPERIMENTAL: Union of possible value types for a Session Option to be set
to.
+ */
+message SessionOptionValue {
+ message StringListValue {
+ repeated string values = 1;
+ }
+
+ oneof option_value {
+ string string_value = 1;
+ bool bool_value = 2;
+ sfixed32 int32_value = 3;
+ sfixed64 int64_value = 4;
+ float float_value = 5;
+ double double_value = 6;
+ StringListValue string_list_value = 7;
+ }
+}
+
+/*
+ * EXPERIMENTAL: A request to set session options for an existing or new
(implicit)
+ * server session.
+ *
+ * Sessions are persisted and referenced via RFC 6265 HTTP cookies, canonically
+ * 'arrow_flight_session_id', although implementations may freely choose their
own name.
+ */
+message SetSessionOptionsRequest {
+ map<string, SessionOptionValue> session_options = 1;
+}
+
+/*
+ * EXPERIMENTAL: The results (individually) of setting a set of session
options.
+ */
+message SetSessionOptionsResult {
+ enum Status {
+ // The status of setting the option is unknown. Servers should avoid using
+ // this value (send a NOT_FOUND error if the requested query is
+ // not known). Clients can retry the request.
+ UNSPECIFIED = 0;
+ // The session option setting completed successfully.
+ OK = 1;
+ // The given session option name was an alias for another option name.
+ OK_MAPPED = 2;
+ // The given session option name is invalid.
+ INVALID_NAME = 3;
+ // The session option value is invalid.
+ INVALID_VALUE = 4;
+ // The session option cannot be set.
+ ERROR = 5;
+ }
+
+ message Result {
+ Status status = 1;
+ }
+
+ map<string, Result> results = 1;
+}
+
+/*
+ * EXPERIMENTAL: A request to access the session options for the current
server session.
+ *
+ * The existing session is referenced via a cookie header; it is an error to
make this
+ * request with a missing, invalid, or expired session cookie header.
+ */
+message GetSessionOptionsRequest {
+}
+
+/*
+ * EXPERIMENTAL: The result containing the current server session options.
+ */
+message GetSessionOptionsResult {
+ map<string, SessionOptionValue> session_options = 1;
+}
+
+/*
+ * Request message for the "Close Session" action.
+ *
+ * The exiting session is referenced via a cookie header.
+ */
+message CloseSessionRequest {
+}
Review Comment:
For the initial session creation, shouldn't it be possible to combine with
the handshake? It is used only for auth, but it could be changed to be used
also if session options and/or auth is to be configured? (otherwise to be
skipped?) (I'm assuming that most people may actually set auth already)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
