Fw: [Oberon] Native Oberon on SourceForge

[John Drake]

--- Vasile Rotaru <vrotaru at seznam.cz> wrote:
> 
> Chris:
> 
> > 
> > Is sourceforge going to offer anything that ethz
> can't/won't ?
> > Is this further fragmentation ?
> > 
> > == Chris Glur.

Hello all,

I agree with Vasile points.  (Well, most of them.
I'm not sure that NO is "orphaned".  But someone
from ETH can better comment on that).

The answer to Chris first question boils down to
two points, stability and end user control.  Namely
ETH can't offer a truly stable code repository in
the same way SourceForge can and ETH won't offer
the same level of end user control.

Chris mentioned Guy Laden's website.  That was once
the best reference on Oberon available, and it's
still halfway decent.  But it's a good example of
the problems generated by "centralized" web
management.  Many links are dead.  For instance
I've made two sourcecode contributions that showed 
up at Guy's site and they're both dead now.  One
was in the form of a newsgroup post (still available
at google.groups), the other was a link to code that
I had at my webspace in grad school.  Since I'm no
longer there the space has been "reclaimed" and hence
the link is dead.  Guy put my "usenet post" on his
website, but since then he's reorganized stuff so
that link is dead also.

This illustrates two problems:

1) Only Guy can fix dead links
2) University web storage is "transient".  For 
instance, many of the "broken links" are to 
projects at ETH that are no longer active.  

Fixing problem #1 is as simple as reorganizing the
site as a "Wiki" (better end user control).  
But #2 is more problematic.  Unlike SourceForge
the "mission" of ETH is not to be a code repository.
So while the current people at ETH might be dedicated
to keeping all of the current Oberon software 
available, there's no guarantee that someone else
down the road might not "reorganize" things again.

As a contributor to ETH you're also left to the
"whim" of the site maintainers.  So far I've
contributed two code packages to ETH.  One is
a PacMan game, the other an XMLRPC client.
Frankly I think the XMLRPC client is a more
significant contribution, but only the PacMan
game is listed on the contribution page.
(You can still find the XMLRPC client if you
"browse" the anonymous FTP site.)  There are
other "gems" hidden away like that, for 
instance the System 3 spreadsheet gadget.

Also, as Vasile pointed out, it's not easy
to make changes to the underlying "system"
available to others.  Would doing that lead
to some fragmentation?  Yes.  But then such
fragmentation hasn't crippled Linux from what
I can see.  And as Vasile also pointed out,
this would be a good chance to "rethink"
some things.  For instance, as many know,
I've never liked module Dates in System 3.
I prefer the Linz V4 dates module which
lets the end user decide whether Sunday
or Monday will be the first day of the week
based on what's most appropriate in his own
country.  Also unlike the Sys 3 version, it
lets you change your date output format
without having to restart Oberon.  But
module Dates is bound to the kernel because
the kernel imports Strings which imports
Dates.  Strings imports dates because it
does date-to-string conversion.  (Module
Strings has several problems).  It would
be better to move date-to-string conversion
to module Dates and only do conversions
of intrinsic types in module Strings.

I think some things are "fixable" without 
causing catestrophic incompatibilities.  But
it will require much thought.

Regards,

John M. Drake

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree