[Oberon] Re. Oberon database application framework

[John Drake]

--- easlab at absamail.co.za wrote:


> John M. Drake wrote:-
> > I've uploaded it to the WebDav.  You can download
> it
> > from:
> > 
> > http://webdav.ethz.ch/jmdrake/DpsAF.zip 
> 
> OK, good, thanks.

You're welcome.

> Looking at the dir of contents:
> UserGuide.Text	 19.08.2004 22:20:14	13132	59%	
> 
> But Id UserGuide.Text is already used, so
> temporarily do:
>  System.RenameFiles SYS:UserGuide.Text =>
> SYS:ObnUserGuide.Text ~
> and extract and examine the 'new' UserGuide.Text ==

Well the easier way around this for "exploration"
purposes is to select the file UserGuide.Text in
the ZIP archive and click the "open" button at
the top of the window.  That way you can open
the file without overwriting anything.

> (** Dps Application Framework, Copyright 2004 DP
> Sisteme 2000 srl *)
> ...Everything is written in Oberon, except DpsServer
> module witch is in 
> Active Oberon. ....
> 
> Well since I don't [yet] use Active Oberon , that's
> the end for me ?
>From the documentation:

===================================================
The server side is working on WinPlugin (only the
local version), WinAos and Aos (the network version).
Everything is written in Oberon, except DpsServer
module witch is in Active Oberon.
===================================================

WinPlugin Oberon has a Native Oberon compiler as
opposed to a "Active Oberon" compiler.  So it sounds
like the "local version" can run under Native Oberon.
It's just the "networked version" that requires
Active Oberon.  At least that's the way I read it.
 
> Packages should introduce their requirements in a
> heirarchy
> to enable the 'investigator' to abort as soon as
> possible, i.e. with
> minimum cost.  I.e. one should be able to fetch the
> requirements
> and minimal description without 'buying' the whole
> package.

Well it was quite obvious to me that this is 
"alpha" software.  In other words, not only is it
free, but the author was quite clear this is a
"work in progress".  (i.e. he had just barely
finished some preliminary documentation).  
Considering how small the download was there's
very little to "buy".  Most open source software
comes with a README.txt.  This one came with a
"UserGuide.Text".  You can open that without
installing anything and see the requirements.
Or if this ever gets added to the ETHZ
"contributions" section that's usually added
with a seperate HTML page that includes
requirements section.

> This common sense principle eg. that each
> contributor's directory 
> should have a standard ReadMe&Contents .....

Or "UserGuide.Text"?  Any reason why it would
have to be named "ReadMe"?  And if you're
worried about overwriting the old 
"UserGuide.Text" you can have the same 
problem with multiple packages that use 
"ReadMe" files.  The only way around that
would be to use a prefix i.e. 
"DpsUserGuide.Text".

> These rules need to be WRITTEN DOWN.
> The developer becomes so engrossed in his
> 'technicalities' that he
> can't be bothered with these apparent trivialities.
> The same way as societies use methods formulated
> thousands of
> years ago [Greek, Roman civilisations] , software
> development is
> a human 'emergent' activity where proven good
> methodology 
> should be copied from the past and not reinvented,
> painfully every
> time.      I.e. written rules/guidelines.
> 
> Why is TextGadgets.Mod included in the zip-file ?
> Comparing with my 2001 ver, it IMPORTs the extra
> module
> "Attributes", used in single statement:
>   	Attributes.SetBool( M.dlink, "Modified", TRUE );	


> What is the rule about contributors [NOT] modifying
> 'core'
> [or any existing] modules ?
> 
> Are there any rules, or even guidelines ?

>From the documentation:
====================================================
The first group are Oberon modules with very few
changes (look for Dan or Alex comments). I hope 
one day I'll find time for better implementation 
then modifying the distribution modules.
====================================================

I don't think the word "rule" applies here.  Once
again this is "alpha" software.  Everyone software
author has to decide on his own where the "balance"
is between releasing something and perfecting it
first.  For instance I've had a "Wolfenstein 3D"
like "raycasting" demo done for a couple of years
that I never released because it wasn't quite
"finished".  But could someone else have gotten
something from it?  Who knows.  The last thing
that we need is for others to come to the 
conclusion that they shouldn't even release free
alpha software because they haven't met all of
the "requirements".  

I see this as a "Check out what I've done
and help me improve" release as opposed to a
"here is something you can use to manage your
e-commerce site" release.

But here's my "suggestion".  Dan could "prefix"
every Oberon module he includes in his distribution.
i.e. TextGadgets.Mod could become dpsTextGadgets.Mod.
Then when he imported this module he could use an
the alias:

IMPORT
   TextGadgets := dpsTextGadgets......

Or, since this is hosted under my subdirectory on the
WebDAV, I could make the changes myself and announce
what I've done.  That's the "bazaar" way of software
development instead of the "Cathedral" way.  Google
"The Cathedral and The Bazaar" for more information
on this.

Anyway I can better recover from "end programmers"
rewriting "core" files than I can "system 
distribution programmers" change core interfaces.
(FileDir.Mod for example is different in different
distributions.  But that's another thread.)

> Where are the [obviously existing] linux guidelines
> kept ?
> I'll ask on NewsGroups.
> 
> Is there a better method of capturing/stealing a
> collaborative
> development METHODOLOGY than copying Linux's ?

I don't believe there are any "official" Linux
guidelines.  As I've mentioned, Google "The
Cathedral and the Bazaar".  Under this model
(used extensively in Open Source software)
rather than simply having "end users" that
"complain" about what they don't like, everybody
takes "owernship" of the overall product/process.
If you have changes you'd like to see made in
a product, make them yourself.  If the changes
are popular they get "folded" back into the
original product.  Or there may be a "branch"
in distributions.  But there's really no way
to enforce "rules" on free software.  Besides,
there are people who are more than happy to
take "rough" software and aid in the development
process.  Why should they have to wait until
software is "end user ready" before having a
chance to see it?
 
> Or do ETHZ originated projects not need a proven
> methodology:
>  they can just wing it ?
> 
> Or is it taboo to discuss this ?
> 
> == Chris Glur.   

It's not taboo, but it would probably be better
received if you were to try your hand at 
development also.  Then it becomes a discussion
of how "we can better do things" rather than
how "you guys ought to be doing things".

Regards,

John M. Drake

P.S. How's that Oberon "Google" engine coming?


		
__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now. 
http://messenger.yahoo.com