Ivan Shmakov wrote:
Miles Fidelman <[email protected]> writes:
Miles Fidelman wrote:
[…]
>> What I mean is that
>>
gnunet://fs/sks/TU6GGH9COPQLPQTG919BB0QVEVIO1SF1IRGI7ACBGOHKVPNCGRUQG98H4DTTPDNDVMV83E8SI51GR66AL6S47BLLK4LULR8J1A7T188/ivan
>> requires that you have the gnunet software installed, and generally
>> you are typing that URL into the gnunet software. It's not like
>> there's a gnunet protocol and API that is generally accessible
>> across the net. This is simply a representation of a gnunet DHT
>> key.
> To clarify just a bit more: The "scheme" portion of a typical URI
> implies a communications protocol, usually involving "listeners"
> sitting out on the net somewhere that understand the particular
> protocol.
I believe that in the above you've meant UR*L*'s specifically,
and not URI's in general.
Actually, no. URL is a deprecated term.
URN is actually a scheme, of the form URN:namespace:specific part, and
typically there are resolvers for URNs that turn them into URLs, though
the specifics tend to be different for different URN namespaces.
A well-fleshed out example is the "handle system" - see RFCs 3650 3651,
3652.
A handle takes a form that looks like: /1711.web/biologicalabstracts/
If you've installed a handle resolver plug-in, into your browser, you
can simply type:
handle:/1711.web/biologicalabstracts/
into the URL box
the plug-in uses a well-specified protocol to talk to a "handle resolver"
If you DON'T have the plug-in, there are public resolvers that you can
use, by entering URL's like this:/
http://digital.library.wisc.edu/1711.web/biologicalabstracts/
Either way, what usually ends up happening is a redirection to a
specific URL for the "digital object" identified by the "handle."
> In the case of most DHT's, access is either via a client program, or
> a call into a software library — details of the protocol used between
> nodes running the DHT are hidden from users.
Such details are virtually always hidden from the users. Does
J. Random User understand GET, Host:, and 404 for instance?
And accessing a URL also requires a particular application (such
as a Web browser), or a library (such as LWP) function call, so
it's hardly different to the URN case.
a URI scheme (usually) denotes a specific protocol for how a client
(e.g., a browser) talks to a server, or to a name resolver - the
exception being some URN namespaces that only provide identification,
but not an inherent access mechanism
it doesn't matter if a user sees the protocol or not, but the user's
AGENT (client software) talks that protocol to servers and/or resolvers
- allowing for a wide variety of interoperable client software
that's very different from the case of client software where the
client-server interface is simply a remote procedure call across a
software interface
> So... gnunet:...., or more accurately urn:gnunet:.... might work as a
> URN scheme (a way to name things) but would not be very useful as a
> way to actually access anything.
It's better to say that URN's allow the resources to be named
/irrespective/ of the particular protocol that may be used to
access them. Effectively, the choice of the protocol is up to
the receiver of such a URI (an application), not the provider,
as in the case of the more common URL's. Which, to me, seems
like /the/ difference between URN's and URL's.
ummm.... not really... most URN namespaces have a specific resolution
protocol associated with them, and there is movement afoot to
standardize this protocol
> (If I haven't been paying attention, and there is something like a
> "gnunet access protocol," complete with resolvers that sit behind TCP
> or UDP listeners, somebody please correct me!).
Unfortunately, I fail to understand this sentence completely.
There's indeed a “GNUnet protocol” (or a suite of protocols),
and all the nodes necessarily have listeners, etc.
Think SMTP vs. IMAP. Mail servers talk SMTP to each other, clients use
POP or IMAP to read mailboxes. Separate protocols, for separate purposes.
GNUnet has one protocol for node-to-node communication, which has a lot
to do with how key-value pairs are distributed across nodes in the
distributed hash table.
What GNUnet DOESN't have (I don't think) is a well-defined interface for
simply getting/putting stuff from/to a hash table. Without that, the
notion of a URI scheme doesn't make a lot of sense.
However, as I've noted before, it isn't strictly necessary to
use such a protocol to access a resource named in a GNUnet (or
Freenet, or BitTorrent) way, and indeed there're BitTorrent
implementations that, failing to locate peers for a given
resource, resort to downloading it off one or more HTTP servers.
(There're provisions for that in the software, and in the
magnet:, Metalink, and .torrent formats.)
Absolutely true, but... the whole point of having a standard naming
scheme is to have a standard way to resolve references, and act on the
resolved objects.
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
