On 11/30/21 16:17, Stephane Tougard wrote:
> On 2021-11-28, rtr <rtr@nospam.invalid> wrote:
>
>> I do agree that gemini should be a "read-only" protocol with
>
> I don't.
....
>
> We need the ability to receive and send information, build forms and
> dynamic software to answer those forms.

I think what will happen with time is simply that people will answer
those shortcomings by methods and protocols on top of Gemini that are
not defined in the standard.

For example, links to images could be automatically expanded, sound
files will show a mini-player, the browser will auto-fetch all links and
show a mini-preview if you hover them, it could show a slideshow gallery
if it finds mostly images in a folder structure and so forth.

Also if no other way exists for people to write comments on pages,
someone will eventually write a decentralized Dissenter-alike "plugin"
and put it inside the popular Gemini browsers. This plugin then simply
operates a database (e.g. GunDB) outside of the Gemini network and
allows comments to any arbitrary URL on it.

The same could be true for polls or any sort of user feedback.

I think this is a much more preferable way to have user interactions,
and one that is much safer from a democratic perspective, than if all
the housekeeping, form building and authority was left to the website
operator.

However if we are talking about non-standard tags becoming popular to
display inline content, like tables, images sound files and maybe even
stuff like webassembly and Javascript-ed webapps, then it gets kind of
messy and shady.

I think it cannot be ignored that there is a critical need for people to
be able to interact with a website, e.g. in the form of giving feedback
or submitting forms (for example a poll, advanced searches with multiple
variables and parameters, inputting data like addresses and statements).

Also there is a critical need to eliminate click-mazes, hence a need to
be able to auto-load and display inline content.

If those needs are not met by the protocol, eventually people will
basically just ignore sticking with it and find ways around it.

Cyrus Valkonen <cyrus.valkonen@gmail.com> wrote:
> I think what will happen with time is simply that people will answer
> those shortcomings by methods and protocols on top of Gemini that are
> not defined in the standard.
>
> For example, links to images could be automatically expanded, sound
> files will show a mini-player, the browser will auto-fetch all links and
> show a mini-preview if you hover them, it could show a slideshow gallery
> if it finds mostly images in a folder structure and so forth.

An implementation could do this at a user option (possibly with lazy
loading), if wanted. It could also be a menu to select modes, e.g.
document, grid gallery, slideshow gallery, etc.

> Also if no other way exists for people to write comments on pages,
> someone will eventually write a decentralized Dissenter-alike "plugin"
> and put it inside the popular Gemini browsers. This plugin then simply
> operates a database (e.g. GunDB) outside of the Gemini network and
> allows comments to any arbitrary URL on it.

Anyone who wants comments in their document can add a mailto: or nntp: or
news: link if they want to do. Therefore there is already the way to do.

If you want to make comments for arbitrary URLs, then you could also use a
NNTP set up for such a purpose, with a new header field to specify what
URL it is being made a comment of, I suppose.

> The same could be true for polls or any sort of user feedback.

I had made up a file format for survey/poll; like Gemini format, it is a
plain text file, and can also be suitably displayed and printed out even
with software not understanding this specific format. I also made up the
answer format, for submitting answers. It is independent of the protocol.

I wrote a parser but not the further parts of it yet, such as the storage
of the answers in a SQLite database (then it is possible to make queries
to calculate statistics that you want, such as mean, median, histogram,
correlations, and more).

> I think this is a much more preferable way to have user interactions,
> and one that is much safer from a democratic perspective, than if all
> the housekeeping, form building and authority was left to the website
> operator.

Both ways have their own advantages and disadvantages, although it is
also possible to do both.

> However if we are talking about non-standard tags becoming popular to
> display inline content, like tables, images sound files and maybe even
> stuff like webassembly and Javascript-ed webapps, then it gets kind of
> messy and shady.

Pictures/sounds do not necessarily have to be inline; they can also be
user settings (and may also be lazy loading).

Tables for data can be useful, but you might also link to a CSV or SQLite
file with the data; the user might also be able to make sort orders,
filters, SQL queries, etc. Some implementations might be made, which can
have the built-in capability of CSV.

I have read about TerseNet which has WebAssembly but not JavaScript, and
must be explicitly executed by the end user; it won't automatically execute
it, and is not needed to display the document.

I also have my own idea which is VM3 (which I had partially written about),
which has its own markup format and instruction set, and many of its design
decisions are made in ways which I think might be better; like TerseNet it
also requires the user to explicitly execute it. We will see what it is
once it is done, and others who are interested can try to help.

> I think it cannot be ignored that there is a critical need for people to
> be able to interact with a website, e.g. in the form of giving feedback
> or submitting forms (for example a poll, advanced searches with multiple
> variables and parameters, inputting data like addresses and statements).

This must be done in a way which is good for advanced users.

For searching, having data accessible as a file, or using a searching API
(which might be usable as a SQLite virtual table module), can allow to do
some kinds of customized searches; a form is still helpful too in order to
make the common uses. (Downloading as a CSV or SQLite is also possible.)

Data input can have some sort of file format that you can make up the form
and the format of the filling in, that you can also save/recall on disk as
individual files too.

An implementation that can autocalculate some form fields should have an
option for auto or manual recalculation; if manual then you must push the
recalculate command (which might be bound to a key, or a menu item or a
toolbar icon) to recalculate the form.

> Also there is a critical need to eliminate click-mazes, hence a need to
> be able to auto-load and display inline content.

This should be a user option. A user might not want to auto-load content.

Gempub allows inline pictures (using the usual Gemini link syntax) for
pictures that are included inside of the ZIP archive, but this should also
be subject to user configuration.

> If those needs are not met by the protocol, eventually people will
> basically just ignore sticking with it and find ways around it.

You can use different protocols and file formats for different purposes.
One protocol or file format will not help everything. (The same should be
true of character encodings; Unicode is not suitable for everything, nor
can everything always be converted to/from Unicode effectively. TRON also
is not always suitable, but has some advantages and disadvantages over
Unicode for some purposes.)

Possibly, implementations could be made where different protocols and file
formats may be loaded as .so files, and may be written in C. Adding new
character encoding conversions could also be implemented similarly; it may
use a font with that encoding if it exists otherwise convert it and specify
which settings to use if necessary.

For example, an implementation could be made with:

Protocols:
* HTTP and HTTPS
* Gemini
* Gopher
* NNTP
* Local files
* Inline data ("data:" URI scheme)

File formats:
* Plain text
* Gemini
* TRON application databus format
* HTML (limited; e.g. based on Lynx or Links)
* Markdown
* CSV
* SQLite
* VM3 application file (including VM3 markup format)
* Pictures: PNG, JPEG, XBM, XPM, farbfeld
* ZIP archive (including Gempub)

Different implementations may vary in which protocols and file formats, and
which features of them, and may allow a common C interface to add other
formats and change their capabilities. The core system may also then be
modified independently to change the user interface and features which are
separate from the protocols and file formats.

We might also ahve different ideas than the above, too. All of the above is
just my current ideas, and we can have improvement in future, too.

--
Don't laugh at the moon when it is day time in France.

On 6/3/22 3:35 PM, news@zzo38computer.org.invalid wrote:
>
> You can use different protocols and file formats for different purposes.
> One protocol or file format will not help everything. (The same should be
> true of character encodings; Unicode is not suitable for everything, nor
> can everything always be converted to/from Unicode effectively. TRON also
> is not always suitable, but has some advantages and disadvantages over
> Unicode for some purposes.)
>
> Possibly, implementations could be made where different protocols and file
> formats may be loaded as .so files, and may be written in C. Adding new
> character encoding conversions could also be implemented similarly; it may
> use a font with that encoding if it exists otherwise convert it and specify
> which settings to use if necessary.
>
> For example, an implementation could be made with:
>
> Protocols:
> * HTTP and HTTPS
> * Gemini
> * Gopher
> * NNTP
> * Local files
> * Inline data ("data:" URI scheme)
>
> File formats:
> * Plain text
> * Gemini
> * TRON application databus format
> * HTML (limited; e.g. based on Lynx or Links)
> * Markdown
> * CSV
> * SQLite
> * VM3 application file (including VM3 markup format)
> * Pictures: PNG, JPEG, XBM, XPM, farbfeld
> * ZIP archive (including Gempub)
>
> Different implementations may vary in which protocols and file formats, and
> which features of them, and may allow a common C interface to add other
> formats and change their capabilities. The core system may also then be
> modified independently to change the user interface and features which are
> separate from the protocols and file formats.
>
> We might also ahve different ideas than the above, too. All of the above is
> just my current ideas, and we can have improvement in future, too.
>

You just re-created Tim B-L's World Wide Web project from 1990. This was
exactly one of his goals: to have just one application, the browser,
which can access many different information sources and databases
through a series of hyperlinks. The browser would access resources
through many protocols, not just HTTP.

LibWWW, which powered Marc Andreesen's Mosaic browser, had built-in
support for HTTP, FTP, Gopher, Wais, NNTP, and other protocols.

Personal opinion is other protocols should take up the input side of the
equation. At an absolute minimum, raising awareness of the Titan
protocol (which Lagrange supports) would be nice for us to experiment.

I have my own annoyance with Gemini, but I'm not going to go 'heeey we
need the spec changed!' because that isn't going to happen. We work with
what we have.

that said I do like that alt-text for ascii art and or code snippits did
make it in. That, is genuinely helpful.