Re: Re: List of Gwebcache

From: "Philippe Verdy" <[email protected]>
To: <[email protected]>
Sent: Thursday, December 07, 2006 8:29 AM
Subject: Re: [the_gdf] Re: List of Gwebcache


> From: "tavolate" <[email protected]>
>> Thank you for your long response... My client alredy use a text file
>> on my web site for read the urls of gwebcache. The problem is that now
>> I don't find the urls of gwebcache to inclure in my file.
>> But whit this discussion now I know also that the protocol for the
>> communication client to gwebcache is changed.
> 
> No, it is NOT changed. The only thing that is "changed" is the way your servent initiates its first list of Gwebcaches at installation time, because it was demonstrated that hardcoding a list of Gwebcaches that you don't control yourself within your servent was harmful.
> 

Note that by "hardcoding" I mean here any method by which the package used for the installation contains a list of Gwebcaches. This includes even the case where the default list of Gwebcaches is installed as an external file, out of the application code itself.

In other words, the whole installation package, including the application code, and its related files should really not contain any hardcoded Gwebcache URL that you don't control yourself. You will comply with this if you just include the URL of your web-hosted default list.

When doing that, it can be useful to include in your own URL a tracker for the version of the servent. For example:
http://download.example.org/myservent/gwebcaches-1.0.txt
which would track the installation of the version 1.0 of the "MyServent" package available on your "example.org" website, and the content of this text file would provide two things:
* the default list of Gwebcaches for that version.
* an information stating if the version is still "valid" or requires updating to a newer version (and probably a message to be displayed to the user.

If an old version should no more be installed, the returned default Gwebcache list will be empty, and so the servent will not be able to connect to any Gwebcache or to the Gnet, and it will inform the without the update, or without the user providing manually an URL to a GWebcache, or the address of another Gnutella servent.

If you have updated an old version to a newer one (for example 2.0), you can still decide to make all old versions return the same "empty" text file with the same message, by soft-linking "gwebcaches-1.0.txt", "gwebcaches-1.1.txt" and so on, to the same "gwebcaches-old.txt" where you put the information message for your newest version.

You can still control which Gwebcaches URLs will be used by your deployed installers by updating this simple test file. You can also know (using the web hosting provider statistics or the statistics of your webserver if you are hosting the website yourselfor if the provider provides you an access to the website log), which versions are being installed and when (but the statistics will be below the effective number of installations, because of intermediate web proxies which may cache your text file, producing a single access by the proxy for many users behind that web proxy).

This solution scales very well because it benefits of the cachability of the web, especially for static files (like plain texts) that do not require performing dynamic queries, but just performing a basic, cachable, HTTP GET request. Performing such basic HTTP GET request to download a basic text file is a very basic development for your servent, and anyway, every Gnutella servent which is used to download files found on the Gnet, requires a minimum support for such basic HTTP GET request...