Subject: [p2p-hackers] Mirror URIs

From: p2p-hackers@zgp.org (Buffer.OverRun) · Date: Tue Jul 16 00:24:01 2002

i haven't RTFM'd on CAW or OCN yet,  but i have thought of a URI scheme that
is close to what you
are suggesting.

Original Thread:
http://www.shouldexist.org/?op=displaystory;sid=2002/7/12/53049/1427;mode=mo 
derate (down ATM)

may also be on ShouldExist.org in a few days.  :)

the XML files used for the mirror URIs can contain any type of contain.  it
is an extensible format.   the client-side parsers will just need
to know how to handle the different types of data tags in the XML file.  p2p
URIs such as gnutella://, ed2k://, etc. can be specified in the
XML file.

/* <copy-and-paste>

Mirror URIs - a URL Scheme for Handling Data Mirrors
By Buff3r0v3rRun  (BufferOverRun{at}users{dot}sourceforge{dot}net), Section
Brainstorms
Posted on Fri Jul 12th, 2002 at 12:30:49 AM EST

Mirror URIs are intended to make it easy to specify mirrors for content such
as data files and webpages.  The goal is make mirrors of data and webpages
easily accessible through an easy, user-friendly method. This will be
achieved through the implementation of a new URI scheme (mirror://), XML
data files, and client-side parsers.

Original Thread:
http://refl3xion.sourceforge.net/yabbse/index.php?board=2;action=display;thr 
eadid=40;start=0;boardseen=1

----------------------------------------------------------------------------
---- 

mirror URI syntax:

mirror://<server>|<file.xml>|<alt-scheme>|<SHA-1-hash>|
ex: 
mirror://server.com|file.txt.xml|https|282f697143b3f51b9caa090b4e43b59b0a0a4
7e6|
mirror://<server>|<file.xml>|<alt-scheme>|<SHA-1-hash>|

<server> specifies the server that holds the file specified in <file.xml>
<file.xml> it is recommended that the file portion be changed to reflect the 
name of the data that is expected to be retrieved including file extension.
for example, if the file to be retrieved is file.txt, <file.xml> should be
changed to file.txt.xml

the xml file must include:

[mirrors] - this section includes links to mirrors of the file
[volatile-mirrors] - mirrors that are known to have low uptimes 
[highspeed-mirrors] - know high-speed mirrors
[mirror-speed] - optional data tag that can be attached to each mirror.
[filename] - filename of the file to be retrieved. must include file
extension.
[expiration] - must be specified for each mirror in <mirrors> section.
specifies how long the mirrored content is expected to be available.
[hashtype] - type of hash specified in <hash>
[hash] - hash of mirrored content

<alt-scheme> if no alternate scheme is specified for retrieving <file.xml>
the client side parser will assume that <file.xml> will be retrieved via 
HTTP. <alt-scheme> can be any valid scheme such as FTP or HTTPS.

<hash> hash is an optional string that can be added to the URI.  this string
is optional because <file.xml> must contain a file hash for the mirrored
media. the hash specified in the URI must be an SHA-1 hash of the data file
specified in <file.xml> including <hash> in a mirror URI will make the URI
exceptionally long. a side effect of including <hash> in the URI is that
URIs from several different servers can be identified as pointing to the
same content.

*NOTE: this is a brief abstract of mirror URIs.  the intent is to garner
ideas about how to improve mirror URIs and possibly catch the interest of a
few devs. i have had this idea for several weeks. it is related to a larger
project called Refl3xion, that i happen to be lead dev on. i am posting this
here b/c i feel that ideas such as these should be Open Standards and not
proprietary.
< Recipe suggesting website (2 comments) | Open Source / Free Software
Discussion Network (OSFSDN) (0 comments) >
Mirror URIs - a URL Scheme for Handling Data Mirrors | 1 comments ( topical,
1 editorial, 0 pending) | Post A Comment

OCN & CAW none (#1)
by Buff3r0v3rRun  (BufferOverRun{at}users{dot}sourceforge{dot}net) on Fri Jul
12th, 2002 at 12:39:27 AM EST
(User Info) http://OpenP2P.tk

i have not yet RTFM'd on OCN & CAW. it has been suggested before. i will as
soon as i have time. i am also planning interop w/ BitTorrent.  and yes, i am
aware that the URIs i specify in this document are not compliant w/ the
syntax specified in RFC 2396[1] and it's updates[2] & [3].

[1] http://www.rfc-editor.org/rfc/rfc2396.txt
[2] 
http://www.rfc-editor.org/cgi-bin/rfcsearch.pl?searchwords=rfc1808&opt=All+f
ields&num=25&format=ftp&orgkeyword=uri&filefmt=txt
[3]
http://www.rfc-editor.org/cgi-bin/rfcsearch.pl?searchwords=rfc1738&opt=All+f
ields&num=25&format=ftp&orgkeyword=uri&filefmt=txt

</copy-and-paste> */

Buffer.OverRun
OpenP2P.tk | p2pNG.tk | Refl3xion.tk 

----- Original Message -----
From: "Glenn McGrath" <bug1@optushome.com.au> 
To: <p2p-hackers@zgp.org>
Cc: <bradneuberg@yahoo.com>
Sent: Tuesday, July 16, 2002 1:05 AM
Subject: Re: [p2p-hackers] Everything as a page

> On Mon, 15 Jul 2002 20:12:40 -0700
> "Brad Neuberg" <bradneuberg@yahoo.com> wrote:
>
> > The alternative to the Unix file philosophy is the web philosophy:
> > everything as a URI.  You could call this the REST philosophy.  When you
> >
> > are interacting with a URI, you can assume that most of the HTTP
> > semantics work with it: GET, POST, PUT (maybe), etc.  This URI could in
> > fact be a file, an operating system process, a web page, an object, a
> > distributed object, etc.
> >
>
> Yes, URI fits better, it ties a file handle to specific machine(s).
>
> If URI's are what most p2p systems have in common, than why not have a URI
> (or transport) layer that tries to connecting URI's in a secure,
> anonymous, accountable way using some intellegent routing, leaving the
> processing of the content sent/received upto the system that uses such a
> library.
>
>
>
> Glenn
> _______________________________________________
> p2p-hackers mailing list
> p2p-hackers@zgp.org
> http://zgp.org/mailman/listinfo/p2p-hackers
>