Text 738, 285 rader
Skriven 2007-03-22 23:29:37 av Mithgol the Webmaster (2:5063/88)
Kommentar till text 734 av Maurice Kinal (1:140/13)
Ärende: Hypertext Fidonet (Fidonet Global Hypertext Interchange)
================================================================
And about 06:10 22 Mar 07 it was written from Maurice Kinal to Mithgol the
Webmaster:
MK> My point is that perhaps instead of adding new standards we should first
MK> figure out if the current standards are worth carrying around anymore or
MK> if they are dragging us all down.
Perhaps not. If we were to figure out that _first_, then they would be dragging
all of us down just by introducing the need to figure it out before developing
_anything_ modern. Though I don't oppose the whole idea of finding out which
standards are worth carrying around and which are not, I still reverve my right
to propose something brand new from the scratch.
If a new standard (e.g. my FGHI URLs) is proposed, it's not reasonable to delay
it by analising all of the existing standards; you'd analyse only those of the
standards that are the base for the new proposal. For example, FGHI URLs rely
upon RFC 1738, FTA-1006 (RFC 2119), RFC 1630, RFC 2279, FTS-0004, FTS-0009,
FTS-4000, RFC 2045-2049, RFC 2397 and FSC-0071 (in order of appearance in the
proposal). Which of those would you consider no longer relevant, and burdening?
MtW>> I am not sure whether I understand what kind of a backwards
MtW>> compatibility you mean, Maurice.
MK> That is the usual reason cited for carrying on with the current standards
MK> as is.
Ah.
MtW>> define an URL-like way to address messages, files and other
MtW>> resources in Fidonet. There was nothing like that in Fidonet before
MtW>> to be backwards compatible with.
MK> Understood. However that only adds complexity to the issue and does
MK> little to resolve current problems. If your ideas cannot be applied with
MK> current standards as is then perhaps a better way to proceed would be to
MK> identify what is wrong with current standards as they apply to future
MK> proposed standards, such as yours, and perhaps that will help resolve
MK> present and future difficulties. There are many that don't use URL-like
MK> networking and yet can still use networking even on the internet without
MK> changing anything in the current standards as they apply to networked FTN
MK> messages, both netmail and echomail.
While my ideas cannot be applied with current standards, they still don't
oppose. It's rather an extension. I know that there are many ÄÄ many users and
many standards ÄÄ that don't use URL-like networking; however, implementing
Fidonet URLs is going to bring a new level of automation and time-saving, where
subscribing to an echo could be done via single click, etc.
MK> I am still not convinced anything like that is needed at the network
MK> level. How would a change to Fidonet URLs better FTN standards?
I am not sure if I understand the question properly, because these words ÄÄ the
network level ÄÄ may mean all sorts of things. If it were the network layer how
the OSI model ÄÄ http://en.wikipedia.org/wiki/OSI_model ÄÄ defines it, then no;
Fidonet URLs, FGHI URLs, are not designed to control routing. However, you most
likely meant to ask me how would a change to Fidonet URLs make FTN standards
better, and would that URLs become a benefit of mankind :-)
That a good question.
The absence of hypertext in Fidonet is the root of the majority of the net's
disadvantages, most of those are just inabilities to do something important.
I've enumerated such inabilities several times in Russian echomail areas (such
as Ru.FTN.Develop and Ru.Fidonet.Today), so everything I need now is just a bit
of self-translation. Here they are:
1) It is not possible to post a direct hyperlink pointing to a message that
you've met in another echo, and even in the same echo.
Some Fidonet users are posting links to the Web gates (e.g. Google Groups
or Fido Online), which is not elegant. Some use forwarding, cross-posting
and other workarounds causing heavy traffic.
2) It is not possible to post direct hyperlink pointing to a Fidonet user,
so you have to post the station address as plain text. And if the reader is
going to send mail to the designated user, then such a sender would have to
(manually) open his netmail editor and copy the address to it. Though for a Web
user, in such kind of a situation, a single mouse click is enough.
3) Fidonet cannot be illiustrated. Each file that is related to the letter's
contents must exist in the plain text form only. That's why UUE codes are so
sommon, though they are rarely decoded automatically, and that's why external
means of browsing the files in external windows are necessary. Meanwhile in the
Internet there is the Web, where pictures are displayed directly inside the
pages, or as backgrounds, and automatically.
It's even worse: nowadays some Fidonet users are slowly getting into a habit of
posting just an Internet address of picture files, without any alternative text
for those readers who are not capable to connect to the Web right now for
downloading the desired file. Meanwhile in the same Web itself, if it is not
possible to download some picture, then the illustration on a hypertext page is
replaced by an alternative text taken from the 'alt=...' attribute of the same
image element, and that attribute is mandatory in HTML.
(At http://www.ftsc.org/docs/fetch.php?doc=FSC-0081.001 there's a standard
proposed, TYPE-3 packets, a brave effort to provide the ability of sending
arbitrary binary files directly in the letter, without any need for UUE codes.
But it's clear that sending binary files is not enough; only hypertext is
capable of designating the appearance and position of the illustration, and
other necessary attributes.)
4) Fidonet is a color-poor medium, Fidonet is all gray and pale, because it has
no more means of color than _such_ or even #/*_such_*/# construct, and it looks
so extreme in GoldEd+ that not only readers are annoyed ÄÄ even the letter's
authors hate it. And even if a Fidonet user has some courage to use such means
of expression, he still faces the lack of any standard or treaty defining which
colors correspond to which codes. Quite the contrary: each Fidonet user (among
the users of GoldEd+) has his own complex of 'Color StyleCode' settings, once
got from his first source of Fidonet software (sysop or uplink) and since that
time they become his habit. Meanwhile in the Web readers enjoy the full color
space of True Color, and colors are reliable; and color highlights can be
delicate, can be soft, can be elegant.
5) Fidonet makes it impossible to enjoy most of common types of emphasis. You
may not make some text cursive or bold; you may not alter font size to create
more visible headings and subheadings; you may not underline. Though some of
visual Fidonet browsers allow changing of font style, they use still the same
symbols _ and *, used in other software (like GoldEd+) for color-coding. This
brings ambiguity. Meanwhile in the Web there are CSS styles, so various kinds
and types of emphasis are possible: the above mentioned, and changing the
background, and dotted underlines, and font family changes (Georgia instead of
Times, Palatino instead of Verdana, et cetera), color boxes, and so on.
6) And Fidonet characters designed for drawing boxes (so called pseudographics)
rely upon DOS encodings (like CP866), and there are systems that do not support
such an encoding or offer limited support. Sometimes such symbols are harmed by
transit nodes, even echomail hubs, if echomail letters are transcoded between
different operating systems. But, even so fragile and rare, Fidonet pseudo
graphic characters cannot be used in serious drawings besides simple boxes. Not
only a 3D cude with a shadow, but even a simple circle cannot be drawn with
Fidonet pseudo graphics until we become expressionistic and pointillistic ÄÄ
until we rely on something like the artistic feeling of our addressees. Here is
an example of letter O drawn with pseudo graphics:
ÜÛßÛÜ
ÛÛ ÛÛ
ßÛÜ ÜÛß
ßßß
This makes, at best, an artistic impression of roundness. For sure, there are
artists in Fidonet, talented in creating masterpieces of character artwork; for
example, portraits:
.,Üa%oÜ,._
+*?SµSa,,,,..___
`"ÔYµS@%¿,_
__..,,sS¿.
_,aS¿
,SjSSjµb,
,µµ+"` _ `?L
j?¾ .Jb,`µ?TL
?' Õ'+?"_SL`L`"?L
ÆS" jba%SL`S?¾ý??Ô Ô.
j' Sµ?¾a,._ L `?i ?;
j?' .µ?¾"`_,si jL `? ?i
.+" Æ?¾"` _,a7 jµ?*Ï*?SL . ?E
jµµL s? jµ?¾" ` . ?, I
`"Ôý `"ýÏ+ö? j¾" _a@!a. ?,jL, ;
_, .,aSÆL ` JL 1a, ?L
_ab. I?+' j SµjL
_ab,S?" ? j?
jµ?` _.,J7 j'
jS7 _,JS7 ?;
j7.a7?µ7'_da ?i
jµ iaSL i?
jT¾ý"`)Sµ: µ ;7
µµL Ô?7 iE
j?¾"`. `?7 j7 µI
_,aSµL,,µ7' j'jE
`?µ?" _d7L
ÆaÜ,_ `??¾" .sµ ?L
iSa, Y?¾"` ,S ø?.
Åi"Ô+? `?@¾"` µL `"ýÏ
; ?L
; a##SSµ ?a_
; j?ϵI _., ^"ý¾*öSSQjµµSaÜ,
; iI_.,ÜsSL `"µ?¾ýø"~`
iY _.,IØL _,aL jµ7ý`
Åi µ?¾"` ?L _,aL_jSý
_.,Üa ; ?Ô^` ?L _,aµ?¾'?7'
S ; ¾"` ,µL "?jS¾' ??'
µ¾ ,ÕL ` srb ?ý
?¾"` ; ,ÕÆ?¾' ?'
;Y ,Õµ?¾'
ii ,Õµ?¾'
Å; ,Õµ¾'
L,Õµ?¾'
µ?¾'
µ?¾'
¾`
But even such an artwork I had to distort a bit, because otherwise the above
mentioned underscore characters would become interpreted as color coding and
introduce some unnecessary color stripes on the portrait. Besides that, such
powerful gifts are not distributed uniformly by Mother Nature, so we cannot
expect the reserves of artistism and patience necessary to create such a
brilliant masterpiece each time when a Fidonet user needs to embed a picture
into his letter.
Meanwhile in the Web there is a gallery of tools specially designed for coding
and embedding simple pictures, created with lines and gradient fills (so called
vector graphics), into hypertext. There is Flash (created by Macromedia, owned
by Adobe Systems), there is SVG (its specs are open and the format is based on
XML hypertext), and there is even VRML (able to define virtual 3D worlds).
7) Fidonet has no means to write mathematic formulae. Each Fidonet user that is
determined to write a definite multiple integral (or just a Greek letter) is
going to face the pain of absence of necessary means. Some Fidonet users faced
such a despair and started to use TeX markup, which is somewhere still popular
when creating scientific papers, and they interpret TeX themselves, forcing
their brains (and brains of their readers) to make a work which should normally
be done with TeX software; and these people think of their habit as positive,
because otherwise the natural science echomail would not be possible at all.
Meanwhile in the Web there are mathematical markup languages, like MathML, and
seamless intergation of their tags into basic HTML markup is possible. And also
there is an alternative in the above mentioned vector images, which may handle
the same necessary symbols as Bezier curves.
The mathematical abilities of the Web is natural, because both the HTML markup
and some of the protocols were designed by scientists who faced the lack of
necessary tools for net publication of their papers ÄÄ these were scientists
from CERN ÄÄ Conseil Europeen pour la Recherche Nucleaire.
8) An attempt to write the French letters (in the full name of CERN) correctly
fails because of yet another problem of Fidonet: not only abstract scientific
symbols, but also the real characters from existing world's alphabets can not
appear in Fidonet letter if its codepage does not match. For example, R50 uses
CP866, so it's not possible to use Western European or Far Eastern or Arabic
characters in the same echomail letter. Even the combining accents cannot be
used, which makes it harder (sometimes impossible) to disambiguate homonyms if
they are not homophones and have stress on different syllables. There is no
angle quotes, em dashes, etc.
Meanwhile in HTML hypertext there is a code to include Unicode symbols even if
they are not present in the document's basic codepage. That's why a Web page,
even encoded into one of Fidonet's codepages, still may contain phrases in
Japanese, symbols of Orthodox crosses, lines of Sanskrit, et cetera.
So you may see now. Eight inablities, eight disadvantages of Fidonet,
significant enough to cause grief and despair. Yet all of them, so numerous,
have common roots in the absence of hypertext ÄÄ and may be put to end with one
smart move.
This move is simple ÄÄ it's the transition to the global exchange of hypertext
messages, to the Fidonet Global Hypertext Interchange, FGHI, the fig-high.
Delivery and browsing of Fidonet letters written in some Fidonet flavour of XML
hypertext language must be made possible.
MtW>> Making Fidonet a hypertext network,
MK> That can be done at the local level by those wanting and/or needing
MK> hypertext without changing FTN standards.
Now a simple question: what the hell are FTN standards for? They help avoiding
such really nasty situations when different groups of 'those wanting' produce
mutually incompatible implementations of the same brilliant idea, don't they?
MK> There are many text <-> markup language converters/interpretors/etc. I
MK> still see no need to alter standards to suit whatever any individual or
MK> even group of nodes may require or want to satisfy their local users.
With my current proposals (FGHI URLs) I am not going to alter ANY of the
existing standards. I came here to standardize someting that never been before.
MK> The only real issue might be with ascii characters due to a lack of
MK> proper codes to enable other languages within transported messages. I
MK> think that issue needs to be addressed before anything else.
Why before anything else? I recognize and acknowledge that the problem exists,
and my precious FidoML (XML-based markup for Fidonet) is going to be able to
solve it ÄÄ but that's not my top priority. FGHI FidoML requires FGHI URLs.
If you really feel that FGHI URLs are to be delayed before the lack of proper
character codes is addressed, than it would probably be addressed by some other
means, FSP-1030 or something. You don't even need new standards for that.
FSP-1030 is enough.
With best Fidonet 2.0 regards,
Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff]
... 129. I will not force two heroes to fight each other in the arena.
--- Something is rotten in the state of Denmark. (Shakespeare, Hamlet, I, IV)
* Origin: Be careful, the paranoid ones are always wathing you!.. (2:5063/88)
|