[gopher] Question about using Gopher for P2P file transfer instead of HTTP

[Cameron Kaiser]

> Content distribution, such as games, game patches, apt-like
> repositories updates and installation, fetching lots of small files in
> succession, which bittorrent is not all that good at, at least not as
> individual torrent hashes.

If you're talking about fetching lots of small files *in their entirety*
in succession, then yes, Gopher should be lighter weight.

> > What is your need exactly? If it is software distribution, and
> > you're wondering about putting "software packages" on Gopher, then
> > I think you got it wrong: Gopher *does* require a server, just the
> > same as http, so the solution would not be "server-less" anymore.
> 
> Uh, many peer to peer applications used /embedded/ http servers,
> because http is easier to get past NAT firewalls and other network
> impediments. My actual question is, what is the gopher-ish approach to
> caching lots of small files independently, such as software repositories?
> 
> Am I to understand that gopher is not flexible enough to be used for
> caching many small files? I understood that gopher is a lot more
> lightweight than http, and is easier on spotty mobile or satellite
> internet links. I am asking, what is the gopherish way to do this?

On the protocol side, there really isn't one; a request is a request. The
server side might do something special to cache resources, but that's a
factor of the server software.

> I want to use gopher's directory menu system to make it easy to search
> for and find files very quickly as part of an automated process. since
> menus and search capabilties are a built-in inherent part of gopher,
> gopher sounded perfect for this.

This is indeed Gopher's strength.

-- 
------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- Happiness is having a scratch for every itch. -- Ogden Nash ----------------