World: r3wp

there is one very usefull doc describing device communication (don't 
remember the name now), but stil some things are going to be missing 
...

current implementation is not what I thought is going to happen - 
the rehaul of aproach we are taking for schemes. Some ppl are also 
confused by read/write function names vs read, write event names, 
and IIRC Graham also noticed few other issues ...

eg. write ftp://ftp.rebol.com/uploads%matrix.mov

UDP implementation? (Needed for dns:// scheme to work?)

Still need a place for set-net, network timeouts, email object .... 
commonly used parse rules and bitsets, network error handlers

Pekr, there is no "overhaul" of the approach.  I spent several months 
on the new design, and it's much better than R2.  There may be a 
few small tweaks to make and a few issues to consider, but other 
than that, it's quite good.

The first thing people need to know is that THIS IS NOT R2!  The 
first mistake is to approach ports the same as R2. That will not 
work here.

not overhaul of ports, but schemes. Ppl were thinking about FSM etc.

Graham is corrrect.  We need to finalize a base context for networking.

I would propose a Networking Module that can hold misc functions 
and variables, debugging modes, etc.

In R3, you can create a module inline with one line of code.  That's 
where to start.

Once we understand the exports, we can then formally define the module, 
title, export list, etc.

The model is good, but most of the wrapper and helper code needs 
work, or revamping.

Also, for testing purposes... if you need to add a system/standard 
object, just unprotect and append to the object. I think the kernel 
will accept that. (But, do not reMAKE the standard object!)

btw - were exports "finalized? Remember you posted blog about it. 
Ditto read/write topic (Prunning down the read/write blog ... and 
following talking about read/string)

Man this system is slow.... help!  Let's move this puppy!... I mean 
world.

I really think we need an EXPORT word that make exports easier to 
manage. Simple I think.

You were supposed to do the rewamp, no? :-) Now as Graham produces 
schemes, we will be lazy to redo it :-)

I thought it is slow because I run it from USB flash ... I am in 
Hungary on business trip for 3 days .... :-)

Carl, the design od that was finalized and the work will be done 
this week.

Pekr, do you mean rewamp? Are you sure you're not visiting Transylvania?

(Romania)

B: sounds good.

Pekr, seems too slow for USB flash. I think it's on floppy or R/W 
CDROM.

What do you know about those countries btw? ;-) You were supposed 
to - was to BrianH ... I have some 10-15 sec lag here ...

For those countries, maybe next DevCon?

both altme and IOS are not designed for USB. Strange, as altme does 
not have much files to read from (in comparison to IOS chat, where 
one msg = 1 file), but slow anyway  ...

Pekr, I was going to work on the network scheme revamp after that. 
I have to put things I already know how to do first, and there are 
a few LOAD and module changes that have accumulated that I know how 
to do already.

Because they write state variable files constantly for the apps.

eh, I am out from net in something like 30 minutes. The four star 
hotel charges 15 EUR for 100 minutes of wifi. That is stupid :-) 
When we do wifi, we suggest hotels to provide such service for free.

I have AltME running on an SD card, so it's even slower, but the 
big problem is the sending lockups and network dropouts. Chat works 
so much better - AltME 3 can't come quickly enough for me.

off topic guys

Right, thanks.

My issue with the r2 schemes is that too much was abstracted so that 
you could not easily do stuff without rewriting the scheme

having simple port abstractions helps the early user but is very 
limiting to experienced users

So, for hylafax which uses the ftp protocol ... I would have to rewrite 
the whole scheme because the ftp scheme assumed the directory listing 
was always in a certain format etc.

In theory R3 schemes should just handle the protocol overhead and 
provide an abstracted behavior model, then the concrete work should 
be done in the handler or by the port actions.

And it uses STAT instead of STOR for uploading files ...

So, the opportunity for code reuse was limited

Anyway, ... we need some decisions made about the base context, network 
tracing etc

However, FTP directory listings are a different issue, protocol overhead 
that needa a lot of special-case code, as I recall.

so I just approached it by supplying a callback to format the directory

What's with the dns:// scheme ?  How do we overwrite the existing 
scheme which doesn't do much ?  We called ours dns2:// pro tem ...

I guess we need to find the existing scheme and set it to the new 
one rather than just adding it ...

Remove it, then re-add it. But, how are you doing DNS? It's a device.

query on port after connect

so, via tcp: ?

yes http://rebol.wik.is/Rebol3/Schemes/Dns

interesting method

That's what 'lookup is used for is it not?