#3258 assigned defect

The interface for the client-side storage plugin web resource has a one-to-many conflict

Reported by: exarkun Owned by: exarkun
Priority: normal Milestone: storage economics plugins
Component: unknown Version: n/a
Keywords: Cc:
Launchpad Bug:

Description (last modified by exarkun)

Storage plugins can contribute to the web interface on client nodes. They do this by implementing IFoolscapStoragePlugin.get_client_resource. This is somewhat awkward to implement because it does not receive all of the same information that IFoolscapStoragePlugin.get_storage_client receives and collecting that information where get_client_resource needs to be called is challenging to implement.

This divergence in available information is caused by the following conflict. get_client_resource is expected to return a single resource which represents "the plugin". However, get_storage_client is called on a per-server basis to get an IStorageServer provider specifically for that single server. Since a Tahoe-LAFS client can be connected to many servers, this call may be made many times to create many objects.

I don't see any way to easily simultaneously accommodate both of these constraints.

Change History (3)

comment:1 Changed at 2019-10-03T13:56:23Z by exarkun

  • Owner set to exarkun
  • Status changed from new to assigned

comment:2 Changed at 2019-10-03T16:33:24Z by exarkun

  • Description modified (diff)
  • Summary changed from Get the client-side web resource for storage plugins from the storage object itself to The interface for the client-side storage plugin web resource has a one-to-many conflict

comment:3 Changed at 2019-10-03T16:35:43Z by exarkun

Originally I thought that there was a solution to this that involved making a web resource per-storage-server as well. This may indeed end up being a solution but it is more involved than I thought. There still very likely needs to be a per-plugin resource that can act as some kind of container for the per-storage-server resources.

For the time being, I think I can get by with the interface as-is - by imposing some additional constraints on the plugin I am implementing outside of Tahoe-LAFS. At some point I will want to revisit this, though, and almost certainly make interface changes here.

I've edited the ticket description to more directly describe the problem instead of my hypothesized solution.

Note: See TracTickets for help on using tickets.