[Oberon] Eth S3 native oberon development trajectory.

[cglur at onwe.co.za]

Related to the ill advised call for dumbing down n-o's cording
mouse:

Every 11 (or what) years there's a new wave of dreamers who
are going to make a lot of money on the stock exchange.

The oberon community's  waves have a shorter cycle time.
BTW what happened to the 'MS *.net  for oberon' wave ?

That's why I don't look at blue-thing  -- yet.
Sys 3 Ver2.3.6 was stable and serving me well, when beta came
along and everybody was shouting: "jump in, jump in !"

When I reported problems I often had no response: denial nor 
acknowledgememt.   As it turned out the new bugs introduced
in beta and alpha (released in that order) were mostly
'work-around-able' and worth the improvements and extra
facilities.

It's nice to be able to find broad general statements to make.
Unfortunately computer user interfacing is not a hard science
and it seems that particular examples are needed.
{BTW this whole thread is not about computing, but about 
managing oberon's evolution, which is equally soft science.}

Someone wants a simple bullet-proofed system, with a basic
http-getter.   Contradiction of terms.
The Web-browser is perhaps the monster that allowed MS to,
more than other stuff, capture the market. I guess I.E. is bigger
than the complete n-o OS with all aplications ?

Someone said do a google search for xyz.
Surely any 'basic' http getter must be able to 'do a google search'.
 {BTW I predict that if google shuts down, the world economy will feel
  a ripple.}
I needed to retrieve some NewsGroup answers to some very
important questions that I had posed on some *legal* NewsGroups.
This is a typical use of google.  And surely your 'basic http-getter'
must be able to handle it ?

I fetch much http stuff by email, and an email google search showed
that I needed to fetch:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=\
06i96tsrumc779ecc8q2mnnlpg31kjc73o%40news.supernews.com&rnum=6&p\
rev=/groups%3Fas_q%3D%26num%3D10%26as_scoring%3Dr%26hl%3Den%26bt\
nG%3DGoogle%2BSearch%26as_epq%3DAdmissible%2Bevidence%2B%3F%2B%2\
6as_oq%3D%26as_eq%3D%26as_ugroup%3D*legal*%26as_usubject%3D%26as\
_uauthors%3D%26as_umsgid%3D%26lr%3D%26as_drrb%3Dq%26as_qdr%3D%26\
as_mind%3D12%26as_minm%3D5%26as_miny%3D1986%26as_maxd%3D2%26as_m\
axm%3D5%26as_maxy%3D2002

Understandably Desktops.OpenDoc won't handle this long argument.

And also when I try to fetch my target from a live google page, it does
TRAP 7  Index out of range (PC Native 11.10.2001)
HTTPDocs.Request  PC = 5056
...
	host = "groups.google.com"
	i = 256

I looked at the source code a week ago and seem to remember that I 
suspected i = 256 via: 
     NetTools.PathStrLen --> CONST PathStrLen = 256;

Investigating this would require firstly finding out if there is a
maximum "argument length" specified (by RFC ? is it).   I guess
that google is open to feedback, so they would not be operating
out of spec. - for long.

My point is that I and other contributors could put more effort into
advancing n-o along it's existing evolutionary path (to hell with
bird brain drastic rewrites) if the management existed.

The less exciting task of fixing various problems is what is needed,
but as it is I'm not going to invest debugging effort in n-o .

These tasks have different skill sets:
1. programming,
2. system design,
3. managing a project,
4. designing and managing a self managing cooperative project.

Native oberon should be moving to stages 3, 4; which can't be done
with stage 1 skills.

Perhaps it's time to learn from linux - also if/what mistakes they made ?

--- Chris Glur.