Changes between Initial Version and Version 1 of Ticket #573, comment 14


Ignore:
Timestamp:
2013-06-28T06:03:51Z (8 years ago)
Author:
nejucomo
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #573, comment 14

    initial v1  
    11Replying to [comment:8 warner]:
    2 > Please take a look at #467, which is about a tahoe.cfg language for defining storage servers (instead of or in addition to using the Introducer), and attributes like how many shares should be sent to such servers.
    3 >
    4 > As Shawn pointed out, an important feature of this language is to say "do not send shares to myself, even if I'm running a storage server".
    5 >
    6 > I currently feel that #467 (specify the servers in tahoe.cfg) will be more useful to more people than (this) #573 (specify the servers in the webapi call), and easier to implement, if only because to take advantage of #573, people have to write an application which:
     2> [...] to take advantage of #573, people have to write an application which:
    73>
    84>  1. uses an as-yet-unwritten API to learn about a list of servers, or has such a list hard-coded into it
     5
     6If we were to revive this ticket, we should also have a ticket for just such an API!
     7
     8Here are some proposals:
     9
     10* `get_known_nodes(type="storage") -> [conn_info]`
     11
     12* `suggest_nodes(cap) -> [conn_info]`
     13
     14    I'm actually not sure if this is useful since for the client to have a cap, a file was already uploaded.  Maybe it should be called `if_you_had_chosen_where_would_you_have_put_this(cap)`.  ;-)
     15
     16Then if we were exposing the introducer-interaction layer like this, we of course might want:
     17
     18* `introduce_peer(introduction)`
     19
     20A related intriguing potential of #467 is that those configurations can be distributed through tahoe itself, so a friend-net application might have a mapping of `some_context_such_as_friend_name → CAP_OF_SERVER_PREFERENCES`.  It could then use that list for the proposed share-placement API, assuming CAP_OF_SERVER_PREFERENCES has shares placed by the "default" method.
     21
     22Of course, now that app and/or its users have the problem of maintaining that mapping, so this is an incomplete solution.  And since it relies on default share placement anyway, the reliability gains of manual share placement are thwarted.  Hrm.
     23
     24It suggests a sort of layer-confused API:
     25
     26* `upload(data, server_selection_read_cap) -> cap_of_data`
     27
     28* `get(cap_of_data, server_selection_read_cap) -> data`
     29
     30All of these suggestions still have the "discoverability" problem swillden described: how does a reader learn the server selection preferences in the first place?
     31
    932>  1. speaks the tahoe webapi to pass the additional arguments, rather than using the existing CLI tools like 'tahoe backup'
    10 >
    11 > Whereas folks that are on a static friendnet (with perhaps some servers that are larger than others) can all use the same tahoe.cfg server-specification text and then use all their existing tahoe-enabled tools without change.
     33
     34The commandline tools could also be extended.  It does seem clunky, but I'm a proponent of cmdline / webapi parity, where the "ugly details" can be behind verbose options which may be hidden from "normal" `--help` output and only shown with `--help-plumbing-yes-I-really-want-enough-rope` or somesuch.
     35
     36