To: perot@pallas.amp.uni-hannover.de
Subject: Re: [7] STIK: MIDI Ring (fwd)                                                   


On Wed, 26 Feb 1997 09:51:21 Peter Rottengatter <perot wrote: 
>
>Hi Ronald
>
>I need your judgement again. Do you think I've been to bold in my 
>response to Martin-Eric (see below) ? I quoted his whole message, 
>please read it and tell me what you think on this matter.

Ok.  I have read it through and will now proceed to add some own remarks
to the original text below.  I am doing this ahead of any other mail replies
and will transmit it as soon as completed.  You do not say if this mail has
already been sent to him, so I assume speed (of my reply) may be essential.

Each of my remarks contain the string "Remark:" and should be easy to find.
In any case there were not many things I'd have changed, though I would
have expressed a few things differently.

At the bottom of this mail I have added some conclusions I've made on the
background to this source code request, based on my reading of the #stik
IRC logs.

-------------------------------------------------------------------------
Start of forwarded message parts
-------------------------------------------------------------------------

>On Tue, 25 Feb 1997, Martin-Eric Racine wrote:
>
>> On Tue, 25 Feb 1997 19:15:41 Peter Rottengatter <perot wrote:
>> >
>> >Actually when writing up the info for Martin-Eric, I proposed a SLIP like
>> >framing protocol, which for ease of implementation would require the
>> >machine MidiNet address to be less than 128. I reckon 128 machines in
>> >a Midi loop is probably much more than usable anyway. This of course does
>> >not mean that the brilliant idea of using the last IP byte is useless.
>> >It basically means that a MidiNet netmask should be 255.255.255.128, thus
>> >having the last byte of the IP address ANDed with 127 giving the MidiNet
>> >address.
>> 
>> Can you please re-send? My AntMail cleared all of its mailbox this
>> morning, and I could not retrieve the archive you sent me ;-(
>
>Ok, I'll do so. Can't do it right now, though, but by tonight you should 
>have it.
>
>
>> Also, if they're in C, would you agree to sending me the sources to
>> your DIALER.ACC, so I could use some of the routines in my new STiK
>> dialer? Dan has agreed to let me handle recoding the old dialer, as
>
>I'm not sure what all this on the dialer is all about. When I talked to 
>Dan for the very first time, he said the dialer should be a separate 
>tool, and he asked me to code it. This is what I did, and it came to a 
>state where people liked it for it's features. For a full, proper public 
>version I only needed a few bugs in STiK 1 cured (from their appearance 
>they did not seem to require a lot of work to fix them), so that setting 
>of a few specific, connection-related parameter can be done by the Dialer 
>too. I explained to Dan a few times in much details what these are, so 
>that they could be cured, and a proper cleanup of the config files could 
>be done. That bugfix appearently never has been done, so meanwhile I 
>wondered, why should I still withheld the Dialer ? After all it's working 
>fine with all people here. I gave away the binary to quite a few people, 
>and told them to forward it if they feel like doing so. So it's gone 
>public meanwhile.
>
>Now I learn that all this work (to Dan's and maybe a few other's opinion) 
>should be discarded, and instead the code that's been in STiK 1 should be 
>improved to form a reasonable dialer. Do you really expect me to support 
>this ? Do you really think Tim would ask Lonny for his IRC client source 
>code to drum up his own, or vice versa ?
>
-------------------------------------------------------------------------
Remark:

  All of the above is ok by my judgement, though I would probably prefer
  slightly different phrases.  I would rather have used:

Now I learn that all this work, in the opinions of some people (Dan?),
should be discarded....
-------------------------------------------------------------------------


>I can still send you the code, and I won't even need to worry, because

-------------------------------------------------------------------------
Remark:

  You shouldn't even mention the possibility of worry IMHO.  I'd say:
  
I can still send you the code, but it may not be very useful to you for
the following reasons.
  
  Then, in the first sentence below, I would have said.

a) it follows a paradigm which you are unlikely to have encountered before.
   There're only very few comments in it, so it will be very difficult for
   you to come to understand it well enough to make use of it.

  That may seem like a small change, but some people hate absolutes,
  especially when used about what they can accomplish.

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

>a) it follows a paradigm that you can't possibly ever have encountered 
>    before. There're only very few comments in it, so you have virtually 
>    no chance to understand the code well enough to make use of it.
>
>b) large parts are rewritten for use for STiK 2 meanwhile. Especially the 
>    config section has seen major revamping. This unfinished state makes 
>    it even harder to extract anything sensible out of it.
>
>c) it uses a GEM library by a friend of mine and myself. We both agreed 
>    they we'd never give away the source code of it.
-------------------------------------------------------------------------
Remark:  You must have meant "that" rather than "they" in the line above.
-------------------------------------------------------------------------
>
>So if you're still interested, I'd send you the parts of the code. But be 
>warned, it's useless for you.

-------------------------------------------------------------------------
Remark:

  I'd say  "it may be useless to you."  at the end of the last sentence.
  It's a small difference, but some people seem allergic to absolute
  statements of this kind.  (I have been criticized for such myself.)

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

>Then again, I cannot understand why Dan focuses people on work that has 
>been done already. To put it boldly : My Dialer works well, and if the 
>STiK.ACC really does not comprise more than the dialer anymore, why not 
>dismiss it completely and use my Dialer ? This way it's faster, and your 
>efforts can be more constructive by working on something new, either for 
>StiK 1 or STiK 2. Redoing things that nobody has ever said should be 
>discarded is silly and insane IMHO.

-------------------------------------------------------------------------
Remark:

Here he will probably object that the current dialer cannot change all the
STiK parameters correctly using various scripts, but you can counter this
by again emphasizing that this was due to STiK problems.  If STiK has now
been altered to allow this, then you should have been informed of this and
asked to adapt the dialler accordingly, rather than being asked to simply
hand over the project to a new author (which is what it amounts to).

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

>> STiK (TCP routines) is now in STIKTSR, leaving STIK.ACC as a dialer
>> and infobox for STiK. Your own DIALER.ACC has great config tools in
>> it, and allows for wait/repeat/, which is badly needed by people on
>> providers that require several random <return> until the first step
>> shows up for authentification in the script.
>
>Putting a REPT into the original source code should not at all be hard 
>work.
-------------------------------------------------------------------------
End of forwarded message
-------------------------------------------------------------------------

It appears as if Dan with some others have started a new STiK development
group, completely segregated from the list except in that some of them
(but not all) also are list members.  Contact is maintained with a larger
group of list members through IRC, as partly evidenced by #stik IRC logs.
(What they really want secret would be handled in other channels though.)

It would be useless to ask any questions on this in the list (I tried),
since everyone simply denies the existence of a separate group.  The logs
from #stik say otherwise, and there even Nick (who denied it in the list)
says that there are effectively two separate development teams now.

I believe that the goal of Dan is to have Michael White fix PPP for STiK 1,
and then attempt to rework STiK 1 into a modular form so as to make your
STiK 2 development seem unnecessary.  I have seen partial discussions in
the logs on STX stuff relating to STiK 1 anyway.

These plans seem quite futile and doomed to me however, since they still do
require Dan to make all the major changes himself at this stage, which will
not work unless he can devote his time to such work, which he can't. If/when
they realize this, I think they may choose to act as if none of this ever
happened.  I would accept that just to leave it behind us.

If you have not yet read any of the #stik logs, I suggest you do so ASAP.
I do not trust their completeness myself, and have only read back to Feb 15,
but the information available here does complement that in the list with
some information on what Dan has really been doing (and his real attitude).

The URL for the logs is: "http://mnb20.pet.cam.ac.uk/stik/

These logs make very tedious reading, partly due to a weird format requiring
lots of side-scrolling, but are necessary to get the full picture of what
has been going on lately.

Again, I see no point in bringing any of this up in the list, since any hint
in that direction so far has only brought denials and hostility.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
