Text 47892, 215 rader
Skriven 2007-01-29 01:21:01 av FidoNews Robot (2:2/2.0)
Ärende: FidoNews 24:05 [02/05]: General Articles
================================================
=================================================================
                        GENERAL ARTICLES
=================================================================

                 Frustrations of a FidoNet programmer
                 By Michiel van der Vlist, 2:280/5555

Most of us who have at some point in their career had job descriptions
that included "writing computer programmes" will be familiar with the
frustrations of having to meet with the demands of customers and
management. What customers and managers usually have in common is that
they can not program themselves out of a wet paper bag even if their
lives depend on it, but who nevertheless have firm perceptions on the
ease by which their demands can be met. "I am not a programmer myself,
but this should be easy to add" is heard too often.

All the more frustrating is that ever so often the customer's wish
would have been relatively easy to meet, had the customer come up with
it in an early stage of the project instead of when it is 99%
finished. Honesty compels me to admit that the opposite also happens:
a customer coming up with a wish that just needs a few key strokes to
fulfil, but him/her believing it is major alteration. (And willing to
pay according to his/her beliefs...)

When writing as a volunteer for a non profit organisation such as
FidoNet, one would hope and maybe even expect to be free of such
frustrations and to just be allowed to program for fun. Unfortunately
this is not true. Not any more I am afraid. Let me give you an example
of something I came across while programming for FidoNet.

When I became R28 pointlist keeper over a decade ago now, I felt the
need for a programme that could not only assemble pointlists from
segments, but that would also check things like flags for correct use
as well. There was MakeNl and there was ERRFLAGS, but the latter would
not work on pointlists and I found it too limited as well. MakeNl was
abanonware at the time and I was not satisfied that either. So I
decided to write my own programme.

Part of this programme was to be the flag checker. Of course the flags
that it recognised should not be hard coded, but be configurable. We
have seen too much problems with hard coding, I did not want to saddle
the users of my programme with the the burden of having to nag for an
update every time a new flag was added to the nodelist. Flags should
be configurable.

Sounds easy. Just make the user enter in the config, a list of flags
he would like to have recognised as valid and if the flag is in the
list, it is ok, and if it is not, generate a warning or an error.
Something like:

FLAGS V22,V32,V32B,V90C,V90S,VFC,V34

But wait, there are userflags and normal flags, so we should have two
classes of flags:

FLAGS XA,XB,XC,XP,XR,XW,XX,CM,MO,MN,LO,V42,V42B,MNP,V22,V32,V32B,
V32T,ZYX,Z19,HST,H14,H16,MAX,PEP,CSP,VFC,V34,V110L,V110H,
V120H,V120L,X75,ISDN,X2S,X2C,V90S,V90C

USERFLAGS NC,REC,NEC,ZEC,ENC,RPK,NPK,CDP,SDS,SMH

All pretty straightforward. Oh, well, there are the Tyz flags. We do
not want the user to have to enter all 2256 valid permutations all by
himself, so we define wildcards for the flags. The Tyz flags are
added:

USERFLAGS NC,REC,NEC,ZEC,ENC,RPK,NPK,CDP,SDS,SMH,T$$

But only a-x and A-X are actually allowed as substitutes for the
wildcards. And permutations with the same letter in the second and
third position are also invalid. Ok, no problem, exclude those
combinations:

EXCLUDEFLAGS TY$,Ty$,TZ$,Tz$,T$Y,T$y,T$Z,T$z,T$<

It started to get a little complicated by now, but still pretty
straightforward. There was one thing still missing though. Flags can
have parameters. Up until the coming of Fido over IP this was not a
big issue as although flags can have parameters, this was hardly used
until the flags for IP and E-mail protocols came into use. The new
flags however van have one or two optional parameters: an address,
host name or e-mail address and or a port number. A decent flag
checker programme should of course check the validity of the
parameters as well. And not just their validity if present, but also
if the required information to make a connection is present. A line
with a lone IBN flag and no hostname or IP address in the system name
field or another field holding a default value should be flagged as an
error.

My first step was to write a subroutine that could determine if a
strings is:
1) a valid IP quad or:
2) a valid fqdn (Fully Qualified Domain Name) or:
3) a valid IPv6 address or:
4) A valid e-mail address or:
5) a valid port number.

Two more classes of flags entered the scene. IPGLAGS end EMAILFLAGS.
The syntax for an IPFFLAG is
FLAG[:<hostname|ip-quad|ipv6address>][:portnumber] and for an
EMAILFLAG: FLAG[:emailaddress][:portnumber].

So in the config this was added:

IPGLAGS IBN,IFC,IFT,ITN,IVM,IP
EMAILFLAGS IMI,ISE,ITX,IUC,IEM,EVY,EMA

Implementing all this was a major operation that required a complete
overhaul of the flag check routines. Not only the flag fields
themselves had to be checked, but also other fields that can contain
default values for the parameters. To show some initiative I added the
feature of letting flags inherit parameters from previous flags in the
same class.

So IBN:fido.vlist.eu,IFC,IFT:fido2.vlist.eu would mean the same as
IBN:fido.vlist,IFC:fido.vlist.eu,IFT:fido2.vlist.eu

Summarising, I had now defined five classes of flags:

1) Normal class flags, no parameters used
2) User class flags, no parameters.
3) Ip class flags, two optional defaultable inheritable parameters
4) email class flags, two optional defaultable inheritable parameters.
5) Flags that are explicitly excluded although defined by implemantion
by one of the other four.

Default port number is of course the default port for the protocol in
question and default parameter # 1 is inherited from the system name
field, or the telephone number field.

Then someone who said "I am not a programmer but..." proposed to put
the default connection information not in the system name field, but
in the field destined for the location, separated from the location
itself by a # character. And it found its way into the nodelist.
Sigh..

I felt uncomfortable about it - Yet Another Method of listing IP
nodes- and the use of the '#' character conflicted with a recently
submitted proposal for listing IPv6 information of the nodelist, but
alas, it was not too hard, so a few more lines were added to my flag
checker routines. But I was getting a bit tired of it. Also my
programme was getting a bit too big for my taste. I was a bit worried
it would become top heavy...

But still the concept of different classes of configurable flags that
each had their own specific syntax and things to check remained. As it
turned out, my efforts to implement that particular way of listing IP
nodes was a wasted effort. It is no longer in use. Not an incentive
really...

And then someone invented the INA flag. Again a politician, not a
programmer. The INA flag should hold the default value for the connect
info for IP flags. It should end all discussion about where to put it
and appease those who refused to give up the BBS name in field 3.

I tried to fit it in, but found I could not without almost starting
all over again and without sacrificing the concept of configurable
classes of flags. I could not fit it in in any of the existing
classes. The INA flag requires one and only one parameter. The other
flags have either none, or two optional parameters. Also, the INA flag
does not stand on its own, if there is no IBN flag or other IP flag,
the presence of the INA flag is an error condition. So I would have to
add a new class just for this flag alone. Adding a class for a single
case almost boils down to hard coding a flag, something I wanted to
avoid.

Top it off with the added complication that there is no requirement
that the INA flag be listed before any other IP protocol flags, so
that in my particular case, I would have to add a separate pass while
parsing the line to extract info from the INA flag, before parsing the
other flags. All the more frustrating is that had it been proposed
five years earlier, I would have started on a different track and
implemented it without much problems. As it is, it just does not fit
in with what I already have. That annoys me.

In the old days, it would go like this: a programmer would write
something into his programme and when people started to use is, the
nodelist clerks would enter the flags needed to support it, into the
nodelist. Programming was fun. It also ensured that by the time a flag
or another feature reached the nodelist, it was always clearly and
unambiguously documented what it was supposed to do. Nothing is as
nitpicking as a computer when it comes to being told what something is
supposed to do. Any ambiguity will be severely punished.

Now, it is the other way around: FidoNet has been taken over by the
politicians. People who by their own admission "are not programmers,
but..." invent nodelist flags. With no regards whatsoever for the few
remaining programmers. How the programmers implement it, is their
problem. No matter how illogical it is or how ill if fits into what
already exists. Programmers are not consulted. The FTSC is not
consulted. When programmers speak up to vent their objections, they
are ignored.  With the result that programmers who have retired from
programming for a living, and who now do it for the fun of it, find
themselves in the same position as when they were still paid for it.
They have to dance to the tune of the customers and the managers. With
the difference of course that they do not get paid any more.

People are afraid that with the few participants we have, changes will
drive people away. If people are forced to change node number, they
will leave they say. But nobody is concerned about an even smaller
group: the programmers. What about them? Should it not be an even
greater concern not to piss off and drive away the programmers by
political decisions that force them to do major rewrites or just throw
in the towel?


(c) 2007, Michiel van der Vlist. All rights reserved.
Permission to distribute via the Fidonews file echo
and the FidoNews echomail conference.


-----------------------------------------------------------------

--- Azure/NewsPrep 3.0
 * Origin: Home of the Fidonews (2:2/2.0)