(???) =======================================: not found
(???) =======================================: not found
Welcome To Cheshire County, NH, USA
(DIR) Cheshire Weather (gopher)
FLGC:
(TXT) Free Libraries Gopher Client 0.2
New in 0.2:
now targets both python 2 and 3 compatibility
(print() / curses work in both)
light support for url proxies
(gopherurl://path/proxy?proxiedgopherurl)
any movement of selection bar shows
current or hovered url at bottom
not new: using "back" autoscrolls to top...
new: except for single step back
(makes it a little less tedious to explore
trees with minimal usage change)
may have fixed cosmetic line width bug
slightly better support of 40 columns
(TXT) Free Libraries Gopher Client 0.1
Our very own command-line Gopher Client (Beta!)
The main strength of the Python/Curl/Curses client
is easy (for us) interface with plugins, filters etc.
Our simple Pygopherd bridge (Coming Soon) works better
with FLGC than Lynx (which it was designed for.)
Version 0.1 supports 0, i, I and 1.
Forg Mods:
(TXT) HOWTO Add "In New Window" to FORG's context menu
(TXT) HOWTO Make FORG Window Title display current URL
Any other mods you'd like to see? Hit the Gmane list.
(No Promises!)
[]- Doing Things The Gopher Way -[]
There is continued debate on Gmane (at least archived
there regularly,) on how to update the Gopher protocol.
It's understandable, especially in light of Gopher+,
that people would want to add features to the protocol.
It's also understandable that people would consider
overloading the client featureset, given that it's
still easier to write a client than the server.
On the other hand, the reason it's easier to write a
client is because the current design is so simple--
unlike (at least less like,) the design of a modern web
browser. Features are easy to add to something simple,
but feature creep reduces the simplicity of future
clients.
There's no authority to pronounce as sin, the act of
creating an incompatible protocol, or incompatible
browser. There *is* a small community dedicated to
reviving an elegantly simple protocol.
The suggestion offered here is to see how much you can
accomplish with the existing protocol. You could always
create a newer system, though it probably won't be any
easier to find users than it is to find users for the
existing protocol. On the contrary, further divide
could decrease interest in Gopher.
The most likely fate of any new gopher-like protocol is
to fade into deeper obscurity and support than the
original; even Gopher+ has much weaker support by users
and servers, despite being supported by UMN.
If it were possible to author a "killer protocol" that
offered both the nostalgic backwards compatibility and
support of the original Gopher, along with optional,
"graceful fallback" support of new features, and it was
"perfect" enough to excite the whole community, that
might work.
Straying much from Gopher would likely be exciting just
long enough for people to lose interest in extra server
setup, extra trouble writing clients, and a few more
people who could revitalize Gopher doing something else
instead.
Why stray much? Rather than start with Gopher and twist
it into Gopheresque, try writing a protocol from
scratch. If it gains use and remains simple, perhaps it
could be backported to some Gopher+ proposal.
Gopher's simplicity is its primary strength, but using
the existing specs, more is possible. Better clients
that use the same protocol are possible. New tricks are
very possible without touching the protocol.
For example: it's almost impossible to create a useful
photo gallery using Gopher. Almost. Gopher doesn't
allow mixing links with images, and any attempt to
make that possible would lead to an explosion of
graphical banners and commercial advertising
possibility (but only *if* Gopher became popular.)
Instead of inline images, we propose image galleries
using existing functionality (in both command line/
framebuffer and existing graphical clients.) It would
not rely on "New Window" functionality, but that helps.
We recommend one Gallery page per folder:
FolderAA(01-20)
FolderAB(21-40)
FolderAC(41-60)
Clicking on FolderAA you get:
(IMG) Gallery01-20
Tip: Try opening Gallery in new window.
(IMG) 01
(IMG) 02
(IMG) 03
(IMG) 04
(IMG) 05
(IMG) 06
(IMG) 07
(IMG) 08
(IMG) 09
(IMG) 10
(IMG) 11
(IMG) 12
(IMG) 13
(IMG) 14
(IMG) 15
(IMG) 16
(IMG) 17
(IMG) 18
(IMG) 19
(IMG) 20
Smaller galleries could include all images, or split
into fewer than 20 images per folder.
In each folder, the Gallery image could show 20
thumbnails as a single image with 4x5 or 5x4 numbered
cells. After viewing this as a preview, the user would
know which number image she wanted to download.
If the user selected her client's "In New Window"
feature, there would be no "Back" navigation needed to
get to the list of full-size images. Either way, it
would be efficient enough to make gallery browsing
possible with *existing clients.*
Before Gopher is added to needlessly, it's worth
exploring new ways to use existing functionality. One
could argue that users who cannot thoroughly exhaust
and employ such ingenuity using Gopher, probably would
not develop a "killer protocol" to replace or upgrade
it, either-- but maybe it's possible.
Whichever is worth more of the community's time and
effort, the community and its members will decide for
themselves. That's the nature of open protocols.
(DIR) ..
(TXT) 2ndwind.txt 2012-May-30 09:37 1.0 KB
(TXT) about 2012-May-16 13:05 0.2 KB
(TXT) flgc.txt 2012-Jul-04 17:35 7.3 KB
(TXT) flgc0-2.txt 2012-Jul-07 20:26 10.3 KB
(TXT) gophermap.save 2012-Jun-06 21:23 5.0 KB
(TXT) urltitle.txt 2012-May-31 12:39 0.7 KB