Text 789, 135 rader
Skriven 2007-03-29 10:44:31 av Mithgol the Webmaster (2:5063/88)
    Kommentar till text 780 av Scott Little (3:712/848)
Ärende: Fidonet URL syntax
==========================
And about 23:34 28 Mar 07 it was written from Scott Little to Mithgol the
Webmaster:

 SL> Placing a file as a direct subordinate of a message echo is already
 SL> synthetic and has nothing to do with reality.  File attachments are
 SL> subordinate of the message not the echo, so the only logical way to
 SL> address them is by linking the message first, then the subobject.

 SL> area://tag/msgid/partid or area://tag?searchfile=filename is logically
 SL> sane. area://tag/filename is nonsense.

Not a nonsense. It's just an abstraction. Physically files are parts of
messages; however, I wanted to divert my implementation from this very fact,
and I had the following reasons:

1) It encourages the uniformity of URLs across schemes, because URLs like
   area://echoname/archivename.zip/subdir/file.ext,
   fecho://fileechoname/archivename.zip/subdir/file.ext,
   freq://node/archivename.zip/subdir/file.ext now have the same form.
   They converge.

2) My standard defines area://echoname/file.ext as the latest posted file
   with the given name (as in file echoes), thus the ablitity to deliver
   dynamic (regularly updated) content is established. Examples:

   *) Daily weather forecast:

      area://weather.forecast/image.informer.apng

   *) Weekly nodelist geoinformational statistics:

      area://nodelist.geodata/weekly_diff.kmz

   *) RSS delivered over Fidonet communication links:

      area://newest.headlines/bash.org.rss

   This makes it logical to define the path similar to paths in file echoes,
   leaving msgids as optional parameters for those who wish a frozen (static)
   version of some dynamic content.

   However, even in such circumstances it's not necessary to use msgids...
   date+time would work as well... that's an interesting idea... I'd probably
   append it to the next (0.4) draft version of my standard.

3) Msgids are not the only parameters that are able to identify messages.
   There could be other means: regular expressions, date+time+author triplets,
   et cetera. I do not want to introduce one of them (msgids) as the primary
   (in the basic part of URL) and all the other ones as secondary (among the
   optional parameters). That's why area://tag/msgid/ is the form I am not
   willing to accept.

 MtW>> not going to invent a tool to bundle off the UUE encoders. Who needs
 MtW>> an URL standard that is not even able to address the files inside
 MtW>> echoes like Fido7.Sound.UUE, Star.Wars.UUE, inside some gamers' echoes
 MtW>> with additional levels, et cetera?

 SL> Who needs a URL scheme that is broken, nonsensical and nonexpandable by
 SL> design?

It is not broken since it works.

It is not nonsensical because I had reasons behind it.

It is perfectly expandable: it allows additional message-identifying parameters
to be introduced.

 MtW>> Though, however, I am still in doubt about whether something like that
 MtW>> is really needed.

 SL> Is FidoML really needed? ;)

1) FidoML would allow message authors to create textual hyperlinks
   (instead of posting just cryptic URLs).

2) FidoML would allow to post illustrations and to define the position of each
   object on the page.

3) FidoML would allow true color tints and shades for text.

4) FidoML would allow message authors to choose between different
   font families and other means of emphasis.

5) FidoML would allow vector images instead of rudimentary pseudo-graphics.

6) FidoML would allow math formulae for echoes dedicated to natural sciences.

7) FidoML would allow inclusion of Unicode characters even if they aren't
   in the current codepage of the letter.

8) FidoML would allow message authors to introduce arbitrary mouse cursors
   when the mouse pointer is hovering over different parts (sections)
   of their messages.

Well I guess there's some need for FidoML after all...

 MtW>> What is more common: different echoes with the same name, or echoes
 MtW>> that are gated across domains so that the echo name persists?

 SL> Othernets typically prepend their network name to every echo tag to ensure
 SL> uniqueness. If not for that, there'd be plenty of conflicting tags.

 SL> I haven't seen any gated echos for a loooong time.. most echos prohibit
 SL> it, and othernets typically exist to provide their own flavour, not simply
 SL> as an extension to Fidonet distribution.

Then I guess we should admit that othernet already have some means to ensure
uniqueness of their echoes... if it's othernet.echoname, then it's probably an
overkill to require othernetdomain#othernet.echoname

 MtW>> probably should just introduce the same 'uplink' optional parameter in
 MtW>> 'area://' scheme that was already introduced in another scheme
 MtW>> ('areafix:') ÄÄ and with an additional note that the conforming
 MtW>> Fidonet browsers should prefer uplinks from the same domain, even if
 MtW>> they can't access the exact node designated in the optional parameter.
 MtW>> Would you be satisfied then?

 SL> uplink aids areafixing, but isn't suitable for uniquely identifying echo
 SL> tags across networks.

True. However, as I've already mentioned above, if the common practice is names
like othernet.echoname, then it's probably an overkill to require monsters like
othernetdomain#othernet.echoname ÄÄ so the domain probably should be optional,
not required.

What would you think about area://echoname?domain=othernetdomain Fidonet URLs,
if 'domain=...' were an optional parameter?


With best Fidonet 2.0 regards,
Mithgol the Webmaster.                 [Real nodelisted name: Sergey Sokoloff]

... 69. All midwives will be banned from the realm.
--- 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)