| 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: |
| | 5 | |
| | 6 | If we were to revive this ticket, we should also have a ticket for just such an API! |
| | 7 | |
| | 8 | Here 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 | |
| | 16 | Then if we were exposing the introducer-interaction layer like this, we of course might want: |
| | 17 | |
| | 18 | * `introduce_peer(introduction)` |
| | 19 | |
| | 20 | A 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 | |
| | 22 | Of 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 | |
| | 24 | It 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 | |
| | 30 | All of these suggestions still have the "discoverability" problem swillden described: how does a reader learn the server selection preferences in the first place? |
| | 31 | |
