Re: [ql-users] SMSQ/E License

2002-11-09 Thread Wolfgang Lenerz

On 8 Nov 2002, at 22:21, Malcolm Cadman wrote:


 There seems to be some confusion around SMSQ/E's 'core' and its
 'flavours'.
 
 It seems to me that Wolfgang has taken on the onerous task of
 maintaining the integrity of SMSQ/E so that it remains consistent and
 coherent, and that all users - irrespective of platform - get access to
 all the 'new' features.

Yipee yey!
Hooray!
Somebody understand what I'm trying to do.

Wolfgang
-
www.wlenerz.com



Re: [ql-users] SMSQ/E License

2002-11-08 Thread Malcolm Cadman

In article [EMAIL PROTECTED], Roy Wood
[EMAIL PROTECTED] writes

In message [EMAIL PROTECTED], 
Dave P [EMAIL PROTECTED] writes
SNIP

The issue I take with it is this notion that all versions of SMSQ/E must
be identical. I think this is not in SMSQ/E's best interest because it
discourages development.
We never said they have to be identical just 'coherent'. Code that works 
on all platforms should be common and code that is specific need not. 
The thing is that all calls to platform specific code should be handled 
by the other platforms without a crash and the whole O/S should maintain 
integrity. This can only be done if the code is controlled and that is 
the post the Wolfgang has taken on. We all want development we also want 
it to work.

There seems to be some confusion around SMSQ/E's 'core' and its
'flavours'.

It seems to me that Wolfgang has taken on the onerous task of
maintaining the integrity of SMSQ/E so that it remains consistent and
coherent, and that all users - irrespective of platform - get access to
all the 'new' features.

So the 'core' remains robust and crash-proof on all platforms, whilst
the 'flavours' can take advantage of the platform's own features.

Hence SMSQ/E - with any new official version - will run on my Black Box
QL + Gold Card, without any problems.  Yet certain features will not be
avialable because the platform simply doesn't support them.

The same new official version of SMSQ/E will run on my Pentium PC with
QPC2 v3, without any problems.  Yet will be able to take advantage of
certain new features.

... and so on for various hardware/software combinations.

Perhaps this warrants a full article in QL Today, and a brief posting on
this list.

-- 
Malcolm Cadman



Re: [ql-users] SMSQ/E License

2002-11-07 Thread Dave P


Before replying to Phoebus' post, I'd just like to say that I have the
utmost respect for someone who changes their mind after expressing a view
for so long.

On Thu, 7 Nov 2002, [windows-1253] Öïßâïò Ñ. Íôüêïò wrote:

 If someone has copies of the list in-or-around '98 he will remember that
 I had a huge discussion with Roy where we agreed on dissagreeing on
 what open software is all about and why it should be supported, I did
 use at that time the same analogy Tony Tebby used (the author and the
 book) now...

I like the intent of the new license - it's just a couple of specific
areas I have trouble with. The license fee isn't one of them and never has
been.

The issue I take with it is this notion that all versions of SMSQ/E must
be identical. I think this is not in SMSQ/E's best interest because it
discourages development.

For example, I think it is good for a version to add a feature that may
not be supported by other platforms, *as long as it is an addition*, and
the software style guide states that if the feature is used in software
released for all platforms, the equivalent functionality should be
included (if possible) for other platforms too.

For example, say a machine is released that requires different code to
operate an IDE interface. That version should be allowed to exclude code
which is simply not relevant, like microdrive-related code, if microdrives
could never be attached to the machine. (this may be a bad example)

That IDE code may for hardware reasons be entirely irrelevent to every
other version, but be required for this version just to achive the same
functionality.

Dealing with the machine at a hardware level, it seems silly to require
that all those patches be included in all versions of SMSQ/E, and/or that
additional features to support extra hardware be globally applied even if
other machines could never support the hardware.

I hope I explained this properly - it's a difficult thing to explain when
I'm tired and can't find the words.

Dave





Re: [ql-users] SMSQ/E License

2002-11-07 Thread ZN

On 07/11/02 at 17:07 Dave P wrote:

The issue I take with it is this notion that all versions of SMSQ/E must
be identical. I think this is not in SMSQ/E's best interest because it
discourages development.

For example, I think it is good for a version to add a feature that may
not be supported by other platforms, *as long as it is an addition*, and
the software style guide states that if the feature is used in software
released for all platforms, the equivalent functionality should be
included (if possible) for other platforms too.

For example, say a machine is released that requires different code to
operate an IDE interface. That version should be allowed to exclude code
which is simply not relevant, like microdrive-related code, if microdrives
could never be attached to the machine. (this may be a bad example)

Then what you really want to say in the licence would be that additions to
SMSQ/E to add a feature of capability to one platform will not be accepted
if it may seriously hinder or even prevent adding an equivalent feature or
capability on another. Obviously, this excludes all platforms where such
feature simply makes on sense or is impossible (by design - leack of need),
but does at least suggest some form of forethought, so that we don't get
'my way or the highway' style features. This breeds tremenodous problems
with writing applications and further additions to SMSQ/E.

Nasta




Re: [ql-users] SMSQ/E License

2002-11-07 Thread Dave P



On Thu, 7 Nov 2002, ZN wrote:

 Obviously, this excludes all platforms where such
 feature simply makes on sense or is impossible (by design - leack of need),
 but does at least suggest some form of forethought, so that we don't get
 'my way or the highway' style features. This breeds tremenodous problems
 with writing applications and further additions to SMSQ/E.

Or does it? My vision is:

Someone writes a spiffy new [item] and it gets included on that version of
SMSQ, because [XYZ] couldn't/wouldn't support it anyway. The feature is
now available if people need it, and they can write applications (remember
when we used to call them programs?) that can benefit from the feature.
Now, your average software author writing for the market can use the
feature if he wants to, but wouldn't want to limit his market to that
platform alone.

This is an *operating system* we're talking about, a way for software to
use the hardware. If code running on radically different hardware cannot
be modified to take into account features of that specific hardware, that
really limits the development of hardware, and of software that runs on
it.

The notion that all versions should have identical features could be
replaced with the notion that all versions should have compatible
features, even if the capability is different. EG: an ARM-QL could support
1600x1200 on a CRT, or 2048x1640 on a LCD. With touch screen support. And
USB. And ethernet. Things that should be included in a monolithic OS.

imvvvho

Dave





Re: [ql-users] SMSQ/E License, Metadrivers and other nice stories

2002-11-07 Thread Phoebus Dokos

??? 7/11/2002 12:07:12 ??, ?/? Dave P [EMAIL PROTECTED] ??:



Before replying to Phoebus' post, I'd just like to say that I have the
utmost respect for someone who changes their mind after expressing a view
for so long.

Thanks.

Please here note that if TT had made a different point in his email my objections 
would still stand on the license... It's just that up until now, I regarded the SMSQ/E 
license under a different light. Truth be told that a program developed continuously 
since 1983 at a certain point stops being a product and becomes a labour of love 
(it's art in its own right). This fact I overlooked. Regarding the rest of the OSS 
world however, I stand by my original opinion, which isn't that much unlike Dave's 
:-)
snip


The issue I take with it is this notion that all versions of SMSQ/E must
be identical. I think this is not in SMSQ/E's best interest because it
discourages development.


I would disagree on that. 
I don't believe that the license's intent to make everything identical.
It's intent as I perceive it to make non-hardware specific functions behave the 
same. In that sense, if you are writing a program that's graphics oriented (to come 
back to my favourite subject), its useless if on a specific platform the same calls do 
different things. In the case of graphics for example I would say that you are 
confusing functionality with output. SMSQ/E achieves that as it stands now in the 
sense that even non-colour aware versions of SMSQ/E (later ones granted) can 
understand the colour specific commands even if the hardware (or the specific 
version's drivers) can't display them. That's not bad. It does ensure a level of 
compatibility which is not perfect but better than nothing
Before something jumps in and says that I said to Roy that if totally new features 
were introduced that made older software incompatible that was okay... please 
note that these features should be available EVERYWHERE... therefore making 
SMSQ/E for ALL platforms incompatible, not just one :-)

For example, I think it is good for a version to add a feature that may
not be supported by other platforms, *as long as it is an addition*, and
the software style guide states that if the feature is used in software
released for all platforms, the equivalent functionality should be
included (if possible) for other platforms too.

Exactly my point :-) And also at least the other be aware of the extra functionality 
and not crash... This cannot be possible with patches (which in the specific Q60 
case may or may not be affecting code functionality on other platforms, but that's 
besides the point here) but only with incorporation in the main source tree...


For example, say a machine is released that requires different code to
operate an IDE interface. That version should be allowed to exclude code
which is simply not relevant, like microdrive-related code, if microdrives
could never be attached to the machine. (this may be a bad example)

That IDE code may for hardware reasons be entirely irrelevent to every
other version, but be required for this version just to achive the same
functionality.

See here you are partially wrong and I will tell you why too. (I owe this explanation 
to Nasta btw)

The problem with QDOS/SMSQ so far (and I believe its the most serious problem) is 
that in reality its drivers are really custom pieces of code (as in code that 
someone would write only to support a specific hardware/software combination and 
that wouldn't be available elsewhere in the OS) that really have nothing to do with 
the OS itself (the famous metadrivers discussion again). While QDOSMSQ provides 
us with the necessary functionality to do these things (and more... Really if we 
think about something new chances are that SMSQ/E already has it... problem is 
Tony never really told us about it... but more on that in a second), no one really 
sat down to write a driver framework (Objects, Methods and Classes... yes in 
reality SMSQ/E is a truly Object Oriented OS) and thus eliminating the need to keep 
drivers in the source tree.

If such a framework is introduced, first of all, all discussion on how drivers and 
hardware specific functionality is implemented will immediately cease. (A very basic 
level of a BIOS equivalent with a quasi-driver of course will have to be maintained 
in the source tree in order for one to be able to boot the machine... that's 
understandable but the drivers in that case being what they should be wouldn't 
cause either controversy or incompatibilities ;-).



Dealing with the machine at a hardware level, it seems silly to require
that all those patches be included in all versions of SMSQ/E, and/or that
additional features to support extra hardware be globally applied even if
other machines could never support the hardware.


True (see my take on the subject above :-) but in any case that wouldn't matter... 
as the interface would be there, just not the drivers... so you call 

Re: [ql-users] SMSQ/E License

2002-11-07 Thread Phoebus Dokos

??? 7/11/2002 1:02:47 ??, ?/? ZN [EMAIL PROTECTED] ??:

snip

Then what you really want to say in the licence would be that additions to
SMSQ/E to add a feature of capability to one platform will not be accepted
if it may seriously hinder or even prevent adding an equivalent feature or
capability on another. Obviously, this excludes all platforms where such
feature simply makes on sense or is impossible (by design - leack of need),
but does at least suggest some form of forethought, so that we don't get
'my way or the highway' style features. This breeds tremenodous problems
with writing applications and further additions to SMSQ/E.

Nasta


While your original proposition (ca. 1995 IQLR) would already have solved the 
problem... Not to mention that with the exception of writing a Memory Manager, a 
Driver API or an internal IP stack (for other purposes eg. making it an embedded OS 
for Internet devices and even that wouldn't really qualify), nothing extremely new 
can be done to improve SMSQ/E which is extremely robust as it is...

Mind you that I believe that the following are not (and should not) be part of the 
OS core:

Drivers (keyboard/screen/serial/disk/sound etc.)
S*Basic
PE
Command line I/F (although for obvious -and historical- reasons these are included 
and perceived as a part of the OS and this illusion isn't really bad)
File System (although some may disagree, but for me the FS isn't nothing more than 
the root object on where other objects (devices) are attached - Again SMSQ/E 
does provide object functionality, just doesn't call it that ;-))


IMHO what SHOULD BE part of the os ONLY:

Scheduler
I/O API (The drivers framework)
Housekeeper (process manager)
Job communication (Call them pipes or what ever you like)
Object Manager (The Thing system)

Phoebus








Re: [ql-users] SMSQ/E License

2002-11-07 Thread Roy Wood

In message [EMAIL PROTECTED], 
Dave P [EMAIL PROTECTED] writes
SNIP
The issue I take with it is this notion that all versions of SMSQ/E must
be identical. I think this is not in SMSQ/E's best interest because it
discourages development.

We never said they have to be identical just 'coherent'. Code that works 
on all platforms should be common and code that is specific need not. 
The thing is that all calls to platform specific code should be handled 
by the other platforms without a crash and the whole O/S should maintain 
integrity. This can only be done if the code is controlled and that is 
the post the Wolfgang has taken on. We all want development we also want 
it to work.
--
Roy Wood
Q Branch, 20 Locks Hill Portslade. Sussex. BN41 2LB. UK
Tel : +44 (0)1273 386030 Fax : +44 (0)1273 430501 (New number!)
Mobile +44(0)7836 745501
Web : www.qbranch.demon.co.uk




Re: [ql-users] SMSQ/E License

2002-11-07 Thread Wolfgang Lenerz

On 7 Nov 2002, at 17:07, Dave P wrote:

(different possibilities on different machines)

I don't know what I'm doing wrong, but, obviously it is something.

I distinctly seem to remember that, as long as something is useful 
only for one machine, I see no problem in putting it in the code for 
that machine.

COnversely, it does without saying that machines that don't have a 
facility (your example of mdvs is great) then they don't have it - Q60 
or the Atari don't have mdv code and why should they?

On the other hand, if some new functionality exists for a machine 
which can be useful for other platforms, why exclude it?

Wolfgang



Re: [ql-users] SMSQ/E License

2002-06-21 Thread Peter Graf


John Sadler wrote:

All your problems would be solved if you use the LGPL license, if the soure
and code is going to be free.
Anybody would be able to sell comercial programs using the updated SMSQ/E
code.
Official versions would still have to be ratified by the appropiate person.

Yes, I think LGPL would do, but even that isn't necessary.
Under GPL, the copyright holder defines what *linking* means.
E.g. he could add this to the GPL copyright notice:

  As a special exception, if *other* files instantiate templates or use macros
  or inline functions from this file, or you compile this file and link it
  with other works to produce a work based on this file, this file does not
  by itself cause the resulting work to be covered by the GNU General Public
  License. However the source code for *this* file must still be made
  available in accordance with section (3) of the GNU General Public
  License.

This way an emulator software, or other parts of SMSQ/E could be *strictly*
commercial, could use all the templates they need, without falling under 
the GPL.
Moreover, it could even be linked into the same binary or ROM.
(Which is not necessary in our case.)

That's how it's done in embedded computing.

Peter