API design revision
The IcatClientInterface
(where IcatClient
is the main implementation from) was originally designed to be used by Bliss
. This has IcatMetadataClient
, IcatInvestigationClient
, IcatElogbookClient
and IcatUpdateSampleClient
as backends. Which makes sense because Bliss needs all of them.
But what about IcatArchiveStatusClient
? Is this used in conjunction with any of the others?
The benefit for a client to use IcatClient
instead of any of the other classes directly is that we hide they way we connect to the backend services (ICAT+ REST, activemq, ...). The only way the client could be affected by any changes in the services is in changes to IcatClient
constructor arguments.
The downside of a single IcatClient
class is that since functionality is growing (CLI tool, Bliss, archiving, MXcube, ...) we will keep adding functions to IcatClient
. Functions that are not available, depending on the IcatClient
constructor arguments you provide, will raise an exception if you try to use them. This approach works but is perhaps not scalable.