[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Namespace creation

From: Christian Grothoff
Subject: Re: [GNUnet-developers] Namespace creation
Date: Sat, 16 Feb 2013 20:22:54 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12

On 02/16/2013 07:50 PM, LRN wrote:
>> Right, if our vision is *one* namespace per user per default,
>> that's fine.  And maybe having the GUI maintain this simplification
>> for good is also fine, as the additional widgets needed to support
>> many namespaces are likely to significantly reduce the number of
>> users that are able to use even just a single namespace.  And for
>> most use cases that I can think of, one namespace should be
>> perfectly sufficient anyway.
>> So I'm fine with one namespace with generated (or default?) name
>> from the GUI-perspective --- right now, I think too few users
>> really understand what namespaces can do, so usability is probably
>> the most important thing to focus on. (Aside from fixing #2564...)
> Since you've mentioned that, how about generating update identifiers
> automatically too? Say, you enter ns element identifier "foo", and GUI
> will immediately fill the update identifier as "foo-2" or something.

Might be a useful to generate something like this by default.

> Obviously, changing update identifier manually will switch that off,
> so when you edit ns element id again, update identifier won't be updated.
> Taking the burden of figuring out update id off users' shoulders may
> help the usability.
> How much effort does FS implementation put into looking for updated
> items in NS? Would it have significant negative impact on the network,
> if we make all ns items updateable by default?

The additional load for update searches should not be significant; the
only possible issue is that one might want to specify "no updates" for
some SKS URI, so that one can also never be forced to produce an update.
But that might also be just a mostly useless feature in practice...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]