[tahoe-dev] Tahoe WUI enhancement suggestion

[Till Steinmetz]

Hi,

wouldnt it make sense if it was possible to directly access the aliases defined in basedir/private/aliases from the web gui instead of only being able to access directorys by uri, or did I oversee the option to do this?

Cheers, t.

Greg Troxel <gdt at ir.bbn.com> schrieb:

>
>"erpo41 at gmail.com" <erpo41 at gmail.com> writes:
>
>> If it helps, I've noticed that Tahoe seems to be designed for use in a
>> business environment
>
>I don't think that's true, although I agree with some of your points.
>My comments are from my own usage that is heading towards a friendnet.
>
>> where one entity controls all of the nodes
>
>I this this is mostly not really true and not really important.   There
>are some issues which sort of relate, but they all feel independent.
>
>> each node has a static IP
>
>My experience has been that the introducer needs to have static address,
>but that storage nodes and clients do not.  Storage nodes do need to
>have a globally-routable address, but that's different.
>
>> there is very little down time
>
>Agreed.  This point (or its converses) is not really well integrated
>into the current code.  Repair has churn when nodes come and go.
>
>https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1209
>https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1210
>
>> very little node turnover,
>
>I'm not sure how much this matters, once the repair-churn issues are
>fixed.  But it's an interesting question.  (One would need to define a
>metric that relates filesystem behavior to node turnover.)
>
>> very high internode bandwidth compared to gateway-user bandwidth,
>
>I don't really follow this.  In my view, the WUI/WAPI should be run on
>computers needing access, and not accessed beyond a thought-secure LAN.
>So I see user-gateway bandwidth as approaching memory speeds.
>
>As for internode bandwidth, client nodes interact with storage nodes
>(yes, I know some can be both).  I don't see that tahoe makes any big
>assumptions here.  I also think that tahoe speed is typically not really
>limited by bandwidth here as much as serializing round trips.
>
>> There are some challenges in the "friends want to pool their extra storage"
>> use case.
>
>True.  The biggest challenges I see are
>
>  accounting, so you can have some measure of fairness (even among
>  friends who are trying to be reasonable, you need a way to know if
>  you've accidentally consuemed 10x what you thought you had)
>
>  expiration/garbage-collection.  There needs to be a way for old shares
>  to go away, but it needs to be safe against normal activities, and
>  safe against vanishing for a few months.
>
>But I also think these challenges are not particularly about
>allmydata.com vs friendnet - they apply to both.  I believe both of
>these are being worked on.   With improvements for those two points and
>fixes for ticket:1209 and ticket:1210, I think tahoe will  be much more
>usabl for the friendnet use case.
>
>
>_______________________________________________
>tahoe-dev mailing list
>tahoe-dev at tahoe-lafs.org
>https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev