Plugin vs. Client vs. ClientManager

[PhilippLgh]

In Grid v1 the plugin design caused a couple of problems. Most notably, the responsibilities of Plugin had no clear definition. It was used to start a binary, set a release and represent a process but also to find releases.

Plugins were directly used in the UI and we even renamed the navigation item from Clients to Plugins.

The problems however are:

• Plugins have no clear entity relationship: they are 1<->1 and 1<->n
• When plugins are started they represent a single version and process, however this relationship can change during runtime when they are re-configured to represent a different binary or process
• The UI needs to keep track of these changes
• And event listeners can easily be forgotten which creates leaks or notifies observers that where interested in process X events of process Y events
• We could only have one running instance per plugin or we would have to display "multiple plugins are used" even though there was only one plugin

In Grid v2 the responsibilities of Plugins are split into Client and ClientManager

Plugins

• Plugins have no longer any logic
• They are evaluated and used to configure instances in our business logic
• This allows us to extend more parts of Grid through Plugins beyond Clients
• If something is a plugin is considered an implementation detail and has no importance to other components. Users and consumers of modules should not care if something is a plugin or implemented as core logic unless it has direct implications (configuring registries)

ClientManagers

• Are created based on client-plugins
• Create Clients
• Are used to query and find specific versions locally or remote
• Monitor the download, extraction etc process
• Help with dependency resolution e.g. Java - necessary to start a Client
• They manage all running instances of a Client type e.g. Geth
• They observe the Client lifecycle, can implement recovery mechanisms for crashing clients or recycle Client instances when they are re-started
• Can be used to inform other parts of the application about updates and legacy versions

Clients

• Are created based on client-plugins
• They represent exactly one version of a binary or running process
• Therefore they implement start(), stop() etc but also communication channels sendRpc()
• Have a lifecycle and allow observers to be informed about lifecycle changes

[evertonfraga]

That feels the right thing to do. Untangling them all will lead to simpler codebase and easier to test code.

really good @PhilippLgh!

[ryanio]

I'm a little hesitant to use the word client again, since it was such a mess last time using it interchangeably with the word plugin. We spent a lot of time refactoring that terminology away.

I have a small feeling we will be going back down the same path again, even though you defined client as: "represent exactly one version of a binary or running process", I'm not sure if it will stand the test of time to being confused with plugin.

I do understand what you're going for though, so I will keep thinking about it and leave any suggestions I may have. @PhilippLgh do you have any alternative words in mind for "client" we could consider using?

[holgerd77]

Also find the terminology confusing on first read, but just as a first encounter feedback, maybe this is valuable (since actually confusion for most people are caused on the first encounter, and not on the "I have thought this through for the last 20 min" moment).

[PhilippLgh]

Thanks for the feedback. Here are my considerations.

Plugin: implementation detail. Likewise we could call clients Objects because we are developing object oriented. Plugins are a software architecture detail and can be used to implement clients, apps, parts of the UI, parts of the server API and just because all of this is implemented as Plugin does not mean we should call all navigation items in the UI "plugin". This changes if we need to communicate with users that something is a plugin and they should extend it. Having a dedicated plugin view could help with this dilemma. Naming it plugin will also make our communication more difficult since Plugin in code means IPlugin interface which acts like a parent class while Client implements IPlugin. So if we talk about plugins "can you change the plugin property x?" we will always have to answer the question with "the Plugin interface, "client-plugins" or some other kind of plugin?". Similar to someone who asks "can you feed the animal?" and gets the response "the cow, the chicken or the dog?"

Node or Peer: is network and graph terminology. Things like zokrates or clef do not fall in this category.

Client: usually used in client-server a client provides access to services. Since most of our binaries implement RPC server / IPC and we connect to it this seems the most reasonable but I'm happy to test this on different personas. From geth github: "geth: Our main Ethereum CLI client."

Binary: could work but is very broad. It also creates confusion if we think of Docker or virtual machines (java) that represent or execute a client script.

?: Open for other suggestions.

Example where our current naming fails: grid.getAllPlugins(onlyDownloaded = false): Promise<[Object]>; This is from our API draft. The problem here is that plugins can be hosted and client binaries are hosted. "onlyDownloaded" in this context could mean "give me all downloaded plugins" or "give me all plugins that manage binaries which are already downloaded". While the meaning is indeed the latter it is confusing and result from unsharp definitions.

[PhilippLgh]

The plugin concept got weakened and client seemed to be the most descriptive yet flexible term after binary. Naming things is hard.. ethereum-binaries has classes for Client and ClientManager