To: stik@on-luebeck.de
Subject: Re: STIK: New proposal: open development of Stik 2.x                            


On Tue, 14 Jan 1997 18:04:52 Martin Mitchell <mem@mode wrote: 
>
>Firstly, some of you have the impression that since we are no longer
>discussing the format of the STiK modules, then I have accepted your
>arguments and now agree upon the Pexec() method. This is not the case.
>I had to suspend my comments over the past few weeks, that is all.

You could hardly expect us to freeze the development until your return.


>I still believe there are many benefits available with a more customised
>module system, and this view was only confirmed when I looked at the
>skeleton of the resolve module, which I received the day before I went
>away.

There are some benefits, yes, but none of any vital importance as I see it.


>The degree of reticence and recalcitrance directed at my suggestion was
               ---------     -------------
>surprising, given that an aim of STiK 2.x was to eliminate the hacks and
>produce a better quality TCP/IP stack. (or so I thought)

The two words I've underlined above can not apply to my dialogs with you,
and the second of them does not apply between equals.  When I disagree
with you I am _not_ recalcitrant, but simply have a different opinion.

Neither of the module loading methods can be considered a hack. And why
should they ?  Both methods are used by various parts of TOS as well as
by other operating systems (incl MagiC).  You might as well argue that
TOS patch TSR's shouldn't be loaded by Pexec, but have a special format.


>Only two arguments seem to be against changing the current model:
>
>1) A lot of code I would need to be rewritten. (perot)
>
>2) It is easier for programmers with different development environments to
>produce Pexec() type STX modules. (dlanor)

There are some more, like the fact that a program started by Pexec has its
own basepage.  This is not only a RAM cost, like you describe it to be, but
also gives some protection from certain types of crashes.  It also allows
the module to own RAM and GEMDOS channels separate from the loading program.
The value of these abilities may be debatable, but they are nevertheless
abilities, and will be lost if Pexec is not used.

More importantly, your arguments against keeping the Pexec method haven't
convinced me that it needs to be replaced at all.


>I shall refute these points now. It may indeed be true that a lot of code
>would need to be rewritten, if a new modules system was implemented.
>However, two points instantly arise: firstly, the longer we leave this,
>the more difficult and complex it becomes to implement, with many more
>code changes to make - the time to change it is now, while the size of the
>code is relatively small.

If (and ONLY if) we assume that the change will have to be made sometime,
then it should indeed be done ASAP.  But since neither I nor Peter share
this assumption with you, such an argument is irrelevant to us.  If I did
believe in that assumption, I would instantly abandon all support for the
Pexec method, and I believe the same to be true of Peter.


>Secondly, the greater flexibility and efficiency
>available in a custom module system in the long term will be worth the
>many changes in the short term. Meanwhile, the Stik API may be closely
>scrutinized for improvements.

All features possible to implement with a custom system can also be equally
well implemented using the Pexec method.  Why call the former more flexible ?
Efficiency is one word with many meanings.  There need not be any runtime
(post-init) difference in speed efficiency between the two methods, and the
extra RAM cost you often have mentioned is not only a loss, but should be
regarded as an investment to gain certain abilities.


>I accept it is easier to produce Pexec() type STX modules. However I think
>that any programmer capable of writing an STX module should also be
>capable of compiling a custom format module. And it isn't as though we are
>talking about many development environments here. Pure C, Lattice C, and
>Devpac are the obvious ones that come to mind. It really isn't that
>difficult to not include the startup code in most C compilers, and of
>course it is even easier in assembly.

I mainly agree. (surprised ?)  Even so, the Pexec method allows the use of
any language which can create a standard Atari executable file.  So, those
who use neither C nor ASM can still develop modules in whatever language
they prefer (eg: GFA Basic).  If needed they can then (after debugging) be
translated into C or (preferably) ASM for time optimization.

It may not be very important, but I see no reason to exclude those who do
not use C or ASM from participating.


>If the reader is still in any doubt about this, just look at the size of a
>'stub' module. It is approximately 2048 bytes per module,

I'm not certain what you mean by 'stub' here, but from the numbers I must
conclude that you include stuff that will also be needed by modules of the
custom loaded kind.


>excluding the basepage size which must be added at runtime.

'Is automatically added by Pexec' you mean, which I still regard as sort
of an investment, half of which is instantly refundable, with the other
half being the necessary key to using some TOS features in certain ways.


>The C startup code is present, scanning for commandline arguments,

That is up to the programmer, and is easily avoided in both C and ASM.


>and the RAM occupied by this code is lost from the whole system.
>Executed once when the module is loaded, this is a clear waste of memory.

No, it need not be (see above), and in ASM it is rather simple to make
sure that all RAM containing init routines is released to the system when
the TSR init is completed.


>There will always be a need for such code to install a module,
>but its size should be minimized.

Sure, which can be done by a great variety of ways with the Pexec method
as well.  For example you can release all RAM holding init code and data
at the end of the program area, simply by specifying a smaller resident
size in the Ptermres call.  Note that this ability is lost without Pexec,
and is not normally possible from high level languages (requires ASM).


>Add to this the space needed for functions/bindings such as strcmp(),
>puts(), Supexec(), replicated for every module, and the inefficiencies
>of the system are apparent.

That is ridiculous.  If a module does not need those functions, their
code will not have to be present, regardless of module loading method.
It is only when someone codes a module using the standard C 'projecet'
or 'make' files that this will happen.  The fact that the Pexec method
allows such programming does not make it mandatory, and hence this is
no argument against the Pexec method.


>Thus, a better module system should be part of a rewritten STiK.

Since each of the arguments you brought up above either have inadequacies,
or were based on erroneous assumptions, I must still disagree.  I still
feel that both methods are viable, with the same two differences that I
have mentioned previously.

1: The custom load method will produce slightly smaller modules.
2: The Pexec method allows some things that others do not.


>At the moment, I cannot support the Pexec() type module system, due to its
>inherent inefficiencies. I have other projects to work on as well, and I
>can only support a project which I am confident is of a sufficient
>quality. I shall have to consider other options for my half complete
>resolver code should the situation remain unchanged.

That is your privilege of course, if you really feel that way about it.

Nevertheless, I wish to remind you that many many projects have been
successfully implemented using Pexec loaded modules.  And as far as
I am concerned this has not diminished their quality one bit, though
I realize that most of them do not use the optimization techniques
that I would recommend for STX modules.

If you really do abandon STiK support over this issue, then I must, with
regret, conclude that you were not really serious about it to begin with.


>In order to facilitate the development of STiK and ensure its future, I
>now suggest that an open development strategy be adopted.
>
>This would encompass the following points:
>
>	- Snapshot release of STiK source code at least every 2 weeks
>	  during rapid development, every month otherwise.

Are you talking of public releases or beta releases ?

Public releases can't follow any strict schedule, since that would mean
releasing changes even when their bugs still remain.

Beta releases should not follow any schedule at all, since they will have
to come in 'spurts' sometimes, due to the debugging/report process.


>	- STiK API to be made public, people on this list should act as
>	  a coordinating committee for the development of the API.

Huh ?  Isn't that mainly what we already have...?

The implemented API is public, and surely you don't mean that the coders
should be forbidden to experiment with new stuff without first getting
a committee to approve it.  In the latter case we wouldn't ever get any
new releases made.  The list already functions as a committee for the
development of ideas concerning all STiK stuff, including the API.


>	- There should be a coordinator for releases, gathering the
>	  binaries/sources of STX modules for release.

Naturally the releases should be coordinated, which has usually been done
by Flinny so far.  As for the sources you mention, I'd leave it up to the
individual authors whether or not they want to release the source as well.
I'm all in favor of their doing it, but the choice should be theirs.


>I think this strategy has many benefits, however I shall await comments
>before presenting my arguments for and against this approach.
>
>Please consider this carefully, as I believe it is very important.

Ok, but I do not see the big difference to how we already do things, except
for the strict release scheduling, which I consider a bit impractical.
Perhaps I have missed some things though, in which case it is best if you
clarify such points, for me and possibly others who also missed them.

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