[tahoe-dev] Roadmap addition: External messaging API?

[Nathan]

To further enable easy experimentation with Tahoe, the webapi should
expose a message passing interface.  Currently, third party apps which
use the webapi can use the storage and directory services, but if they
wish to implement networking features they must do so out-of-band.

As an example experimental extension, consider an alternative to the
vdrive layer which is built on top of the CHK storage layer.  Without
using vdrives, there is no mechanism in the current webapi to
communicate directly with other nodes (aside from inaccessible
storage-layer interactions).

Of course, such an alternative could just be a fork of the source, or
the source could contain multiple overlapping features which are
selected at configuration time.  But I prefer to extend the webapi to
cater to third party extension development.


A messaging API can be very complicated in the face of configuration,
user interface, and access control.  I propose an initial milestone
with this interface:

Top-level:

provide(servicename) -> servicequeue # or failure flag
send(nodeid, servicename, message) -> responsepromise

Message reception:

pop_message(servicequeue) -> (messageid, message) # or empty flag
respond_to_message(messageid, response)

Response handling:

poll_response(responsepromise) -> response # or not-yet flag
poll_responses() -> (responsepromise, response) # or not-yet flag


Suggestions?  Responses?  Vetoes?

Nathan