Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.infosystems.gemini > #555

Re: Another protocol

Show all headers | View raw

Rene Kita <mail@rkta.de> wrote:
> news@zzo38computer.org.invalid wrote:
> > Here is my idea of another protocol and file format, considering what are
> > the problems with Gemini (in my opinion), and how to be better (in my
> > opinion).
> [...]
> > Please make your comments/questions/suggestions/complaints about it.
> 
> Maybe you should provide a summary what problems are solved by your
> protocol. Or give me any other reason why I should read those 500+
> lines.

OK, it is a good idea. (Note that some changes have been made to the
document since the version posted on Usenet though, but the link included
with it links to the most recent version.)

* Perhaps it is something between Gemini and Spartan and HTTP in case you
think that Gemini has some problems, although some things are avoided as
well as being added.

* Many things I find they are either too simple (e.g. Ogg container format)
or too complicated (e.g. the other multimedia container formats). (This is
not only the problem of media container formats, of course.)

* I want to consider low-level programming, and not only high-level.

* Many things are similar than Gemini, e.g. most of the status codes.

* Some things have been added, e.g. telling the file size (if known), and
optional range requests.

* Some things removed or deprecated, e.g. the 11 status code is removed
because there is a better way to send passwords.

* Some things are I have decided against, for simplicity and sometimes for
other reasons.

* MIME has some problems as a file format identification. (UTI has a
different set of problems.) ULFI (unordered labels file identification) is
better, I think.

* Unicode is no good. (There are better ways to handle international text.
And, in some cases (e.g. a computer command), ASCII is better.)

* Titan isn't very good in my opinion, to have the security token in the way
that is does and put file size in the URL (rather than a separate line), and
no handling of edit conflicts, etc.

* Many things are made optional.

* What some other protocol does or does not do, does not require that this
protocol also does or does not do; it has its own reasons to do and not do.

* See also my other article I posted recently to this newsgroup, which is a
response to various criticisms of Gemini (although I also have my own
criticisms, some of which are different than the ones quoted there), which
also explains some of my reasons.

However, this summary doesn't help much; read the actual document and the
responses of criticisms for further details, please.

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

Back to comp.infosystems.gemini | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Another protocol news@zzo38computer.org.invalid - 2023-12-26 17:13 -0800
  Re: Another protocol Rene Kita <mail@rkta.de> - 2023-12-28 10:54 +0000
    Re: Another protocol news@zzo38computer.org.invalid - 2023-12-28 16:45 -0800
      Re: Another protocol Iuri Rezende Souza <iuri@example.invalid> - 2023-12-29 11:24 -0500
        Re: Another protocol news@zzo38computer.org.invalid - 2023-12-29 12:34 -0800
        Re: Another protocol John <john@building-m.simplistic-anti-spam-measure.net> - 2024-01-09 16:29 +0000

csiph-web