Re (2): [Oberon] Win32 Plugin Oberon, status report II

[John Drake]

--- Edgar at EdgarSchwarz.de wrote:

> I feel that delegates make sense (For more on
> delegates have a look at C#).

You're probably right on that.  Like I said I can
see how this adds flexibility.  I wasn't aware
C# had something like that.  But I'm still not
sure how definining a method and assigning it
to a procedure variable in Active Oberon is any
different than defining a procedure and 
assigning it to a procedure variable in 
Oberon-1.  I guess I'll have to study BlueBottle
sample code more deeply.

> But for the purpose of the WebDAV client for Native
> it should be possible
> to do the sending and reveiving to the TCP/IP
> connection without this
> AosIO feature.

Yes.  I feel quite certain that WebDAV can work
without delegates, though I think the port is
more work than either of us first thought.  I'm
taking a look at the DAV code again.  You're on
version 7 right?  Module WebDAV.Mod uses delegates
for the objects ChunkedOutStream and 
ChunkedInStream.  I'll test restructuring that
code and see what happens.

> BTW my first problem came with you AosFS. It seems
> like PluginOberon.Files
> and Native.Files have some differences.
> If you are interested I could give you some details.

Yes.  I would certainly be interested.

> But so be it. I still think that a Native client
> would be worth some work.
> OTOH I expect it to be easier with an upcoming new
> PluginOberon release.

Yeah, I thought about that.  When 
"PluginActiveOberon" comes on line will there really
be any reason to support Native Oberon?  Are there
any advantages to Native Oberon over BlueBottle at
this point?  I'm guessing Native has even less
hardware requirements than BlueBottle, but I haven't
looked into that.

Another thought that this brings mind another idea
I've been kicking around for awhile.  I call it
the "convergent Oberon project".  I don't know
about everyone else, but I'm one of those guys
that lives in several Oberon worlds.  While I
mostly use PluginOberon these days, I still use
V4, occassionally Pow! and of course I experiment
with BlueBottle.  Portibility is a problem.  The
only real attempt that I've seen at developing
Oberon code that worked on different systems is
the Voyager project.  They achieved this by 
running all system dependent code through a
single "porting" module.  It would be nice to 
have a set of "convergent" modules more 
powerfull then the ubiquitous In, Out and 
XYPlane modules.  By convergent I mean that 
they either:

A) Are availble with full source, don't use
any system dependencies and only import
convergent modules.

B) Exist for multiple systems and present
a consistent interface for each one.

Of course the divergence of the Oberon
language put a damper on this idea
(Active/Native Oberon, Component Pascal,
Oberon-2) so I shelved the idea.  But
this experience has brought it back to
mind.  For one thing I've found that even
the Native/Active Oberon compilers have
differences that I wasn't expecting.  Yet
on the other hand I believe these differences
can be worked around, and at least a
(semi) consistent interface can be presented
to the programmer.  Or at least a set
of modules with convergent "functionality"
can be developed.  After all the main
feature of AosIO is that it presents an
extensible "streams" IO system.  But I've
seen something like that for Oberon-2 some
years back.  Just thinking outloud at the
moment.  I won't be able to do anything
on this until I have some more spare time.
*ROTLFO*
 
> Cheers, Edgar

Regards,

John M. Drake


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com