Refactor low level clients #20

ionut-arm · 2020-04-15T11:49:05Z

This commit includes a few changes:

remove explicit wire protocol version handling, following a similar
change in the interface
add a provider ID field to the list_opcodes operation, with the
request being serviced by the core provider
include an implicit provider ID within the basic client to allow it to
maintain a consistent operation while allowing it to expose an interface
that essentially covers the wire protocol contracts
add checks that core operations are only performed on the core client
and cryptographic operations cannot be performed on the core client

Co-authored-by: Ionut Mihalcea [email protected]
Co-authored-by: Hugues de Valon [email protected]

Signed-off-by: Ionut Mihalcea [email protected]

hug-dev

Thanks for doing all of this! The operations look really good now.
Some nit picks about naming.

Some general comments about our file structure:

should we keep the core folder? I think it makes sense in terms of abstraction: it is the core based on which any higher level client can be built on.
you would normally expect the main structure to be contained in core/mod.rs but since our BasicClient has no "core" in it and to align it with the other ones, would it be nicer to have basic_client.rs as a separate file, like operation and request?
we have ipc_client in core, it might be confusing. Maybe it is worth renaming it just ipc or ipc_connectors?

hug-dev · 2020-04-15T12:43:34Z

src/core/mod.rs

 mod testing;

 use crate::auth::AuthenticationData;
 use crate::error::{ClientErrorKind, Error, Result};
-use operation_handler::OperationHandler;
+use operation_client::OperationHandler;


Is OperationHandler supposed to be OperationClient as well?

Yep! It's a bit weird naming all of them clients, but alas... it makes more sense to keep this consistent

hug-dev · 2020-04-15T12:48:11Z

src/core/mod.rs

@@ -190,18 +157,20 @@ impl Provider {
 /// in order to figure out if their desired use case and provider are
 /// available.
 #[derive(Debug)]
-pub struct CoreClient {
+pub struct BasicClient {
    op_handler: OperationHandler,


Here as well, should it be op_client: OperationClient?

hug-dev · 2020-04-15T12:48:55Z

src/core/mod.rs

 }

 /// Main client functionality.
-impl CoreClient {
+impl BasicClient {
    /// Create a new Parsec client given the authentication data of the app.


Maybe this code doc can be expanded to cover how the provider arg is going to be used.

And maybe renamed implicit_provider to match with the set_implicit_provider method

Yep, good point, I tried to update the docs but I forgot about this one!

hug-dev · 2020-04-15T12:55:36Z

src/core/mod.rs

@@ -190,18 +157,20 @@ impl Provider {
 /// in order to figure out if their desired use case and provider are
 /// available.


In this code doc it would be nice also to make the distinction betweem core provider and crypto ones and what it means for the operations. Maybe in the code doc of each operation as well, say if it is a core or a crypto one?

Will try and think of a way to "mark" them somehow in the docs!

hug-dev · 2020-04-15T12:56:44Z

src/core/mod.rs

+    /// If the implicit client provider is `ProviderID::Core`, a client error
+    /// of `InvalidProvider` type is returned.


hug-dev · 2020-04-15T13:00:51Z

src/core/mod.rs

            &self.auth_data,
        )?;

        Ok(())
    }
+
+    fn can_provide_crypto(&self) -> Result<()> {


hug-dev · 2020-04-15T13:01:37Z

src/core/operation_client.rs

 #![allow(dead_code)]

-use super::request_handler::RequestHandler;
+use super::request_client::RequestHandler;


and this one RequestClient as well 😬 ?

hug-dev · 2020-04-15T13:03:35Z

src/core/operation_client.rs

-            wire_protocol_version_min: 0,
-            content_type: BodyType::Protobuf,
-            accept_type: BodyType::Protobuf,
+            content_type: Box::from(ProtobufConverter {}),


Maybe the field name content_converter is more appropriate?

Yeah, I guess, especially since it's public

hug-dev · 2020-04-15T13:04:36Z

src/core/operation_client.rs

    }

-    /// Set the wire protocol version numbers to be used by the client.
+    /// Set the content type for responses handled by this client.


"accept" type?

ionut-arm · 2020-04-15T13:30:52Z

* should we keep the `core` folder? I think it makes sense in terms of abstraction: it is the core based on which any higher level client can be built on.

I think so, it makes sense to have the core segregated, especially if we don't want people to use this too much, we can document it accordingly

* you would normally expect the main structure to be contained in `core/mod.rs` but since our `BasicClient` has no "core" in it and to align it with the other ones, would it be nicer to have `basic_client.rs` as a separate file, like operation and request?

That makes sense!

* we have `ipc_client` in `core`, it might be confusing. Maybe it is worth renaming it just `ipc` or `ipc_connectors`?

Yeah, I noticed that too, will try and think of the proper name for it.

hug-dev

Thanks, that looks very good!

hug-dev · 2020-04-15T16:14:18Z

src/core/basic_client.rs

+    /// The `implicit_provider` will be used for all non-core operations. Thus, until a
+    /// different provider ID is set using [`set_implicit_provider`](#method.set_implicit_provider),
+    /// all cryptographic operations will be executed in the context of this provider (if it is
+    /// available within the service).


Nice, I did not know you could link with methods!

This commit includes a few changes: * remove explicit wire protocol version handling, following a similar change in the interface * add a provider ID field to the list_opcodes operation, with the request being serviced by the core provider * include an implicit provider ID within the basic client to allow it to maintain a consistent operation while allowing it to expose an interface that essentially covers the wire protocol contracts * add checks that core operations are only performed on the core client and cryptographic operations cannot be performed on the core client Co-authored-by: Ionut Mihalcea <[email protected]> Co-authored-by: Hugues de Valon <[email protected]> Signed-off-by: Ionut Mihalcea <[email protected]>

ionut-arm added the enhancement New feature or request label Apr 15, 2020

ionut-arm requested review from hug-dev and anta5010 April 15, 2020 11:49

ionut-arm self-assigned this Apr 15, 2020

hug-dev reviewed Apr 15, 2020

View reviewed changes

ionut-arm force-pushed the reorg branch from 8f72cbe to bf556fe Compare April 15, 2020 14:49

hug-dev approved these changes Apr 15, 2020

View reviewed changes

ionut-arm force-pushed the reorg branch from bf556fe to 7b8b905 Compare April 15, 2020 16:31

ionut-arm merged commit 69af021 into parallaxsecond:master Apr 16, 2020

ionut-arm deleted the reorg branch April 16, 2020 08:48

ionut-arm mentioned this pull request Apr 16, 2020

Make the CoreClient really dumb #19

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Refactor low level clients #20

Refactor low level clients #20

ionut-arm commented Apr 15, 2020

hug-dev left a comment

hug-dev Apr 15, 2020

ionut-arm Apr 15, 2020

hug-dev Apr 15, 2020

hug-dev Apr 15, 2020

hug-dev Apr 15, 2020

ionut-arm Apr 15, 2020

hug-dev Apr 15, 2020

ionut-arm Apr 15, 2020

hug-dev Apr 15, 2020

hug-dev Apr 15, 2020

hug-dev Apr 15, 2020

hug-dev Apr 15, 2020

ionut-arm Apr 15, 2020

hug-dev Apr 15, 2020

ionut-arm commented Apr 15, 2020

hug-dev left a comment

hug-dev Apr 15, 2020

		@@ -190,18 +157,20 @@ impl Provider {
		/// in order to figure out if their desired use case and provider are
		/// available.

		/// If the implicit client provider is `ProviderID::Core`, a client error
		/// of `InvalidProvider` type is returned.

Refactor low level clients #20

Refactor low level clients #20

Conversation

ionut-arm commented Apr 15, 2020

hug-dev left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ionut-arm commented Apr 15, 2020

hug-dev left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment