Text 47909, 233 rader
Skriven 2007-01-29 15:09:49 av Roy Witt (1:397/22)
  Kommentar till text 47892 av Michiel van der Vlist (2:2/2.0)
Ärende: FidoNews 24:05 [02/05]: General Articles
================================================
29 Jan 07 01:21, FidoNews Robot wrote to All:

I'm not a programmer myself, but it should be easy as pie to start
re-coding a new program all over again, with newly suggested perameters.
:o)


 FR> =================================================================
 FR>                         GENERAL ARTICLES
 FR> =================================================================

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 FR> So in the config this was added:

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

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

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

 FR> Summarising, I had now defined five classes of flags:

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

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

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

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

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

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

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

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

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

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

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


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


 FR> -----------------------------------------------------------------

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

               R\%/itt




--- Twit(t) Filter v2.1 (C) 2000
 * Origin: SATX Alamo Area Net * South * Texas, USA * (1:397/22)