>(SFS) seemed like a possible way to eliminate some of the work LISTSERV
>does to simulate a hierarchical file system, and take that burden off
>your back.
I understand that you want to drop the subject, but I want to make sure I
have convinced you that the SFS cannot take any burden off my back, at
least not now. Common sense dictates that you cannot simplify your
(programming) task by relying on a facility, however powerful it might
be, which you cannot use unconditionally. That is, as long as you have to
code "IF <I can use facility> THEN <inst1> ELSE <inst2>", you are making
your life more difficult because you have to code inst2 anyway and now
you are adding the burden of inst1. Doing this might (or might not)
increase performance or provide better functionality when the facility is
available, but it is certainly NEVER going to make your life easier. This
is by the way the only reason why LISTSERV V2 will not support CMS
release 3 any more: I'm sick and tired of coding "If sp4 Then" everywhere
I want to do an EXECLOAD or EXECIO STEM, when almost everybody has CMS 4
or above. I don't *need* to do an EXECLOAD or EXECIO STEM, but I usually
want the performance boost when I can use it, and I'm tired of the IF's.
>Ideally, these services should be specified independently of your
>implementation, so that any user on any system on the network can write
>a compatible server.
Nobody will write such a compatible server. I know it sounds like a
gratuitous and dictatorial statement, but it's based on experience. I
have sent LISTSERV sources, over the last 3 years, to a dozen experienced
VMS programmers (some of which also had a good knowledge of VM) who
wanted to port it to VMS. None of them has produced anything that would
handle even just the distribution list business, which is a relatively
small fraction of LISTSERV.
Maybe it due to the sheer amount of work to be done (30000 lines of REXX
code, 6000 lines of assembler, 12000 lines of documentation and, as you
know, a lot remains to be done in this area). Maybe to the difficulty of
interfacing with the networking software under VMS. Maybe to the fact
that LISTSERV kept changing very fast, when I was working on it full
time. Maybe to the lack of documentation about the internals, but on the
other hand REXX is easier to understand than most programming languages.
If you want to port LISTSERV to another operating system, you have to
face 3 difficulties:
1. Get someone to write a specification of LISTSERV and documentation
about the internals.
2. Find people to write the code.
3. Convince the user community that this implementation can be "trusted"
to join the backbone (for example).
For (1) and (2), you will have to bear in mind that LISTSERV is
constantly changing and that, as they port the software, the poor
programmers will be faced with constantly changing specifications (the
changes would be compatible of course, but the amount of work they have
to do would constantly increase, so that they might get the impression
that they will never catch up).
>As it stands now, around 60-70% of all BITNET nodes are excluded from
>running LISTSERV because they do not run VM.
They can use the LISTSERVs running on VM nodes from their non-VM
machines. That's about as far as I can go.
Eric
|
