World: r3wp

Robert made an overview of how ports work a while ago. I'm not sure 
if it's available publicly.

file io is sync isn't it?

Thats what I wrote

But ok sub port cannot be unleashed from above schema right?

why not?

the main port is just an abstraction .. to allow you to work on the 
real port

Thats what I ask, may the scheme be asynchronous when low level port 
is synronous and we dont use tasks yet?

I don't think so

I guess we'll need device extensions for briging the gap.

briging = bridging

Has anybody tried some file related scheme? zip// or somethink like 
was in disscussion?

I'm missing what is the point?  the network schemes are written to 
try and emulate file io ...

access to RIF?

Graham I like to write a scheme for my mini RIF implementation yes 
maxim

direct DB table access using read/write would be VERY powerfull  
:-)

Ie write number to port get record back, write record to port get 
number back for the very beginning

make-scheme [
	name: 'foo
	title: "FOO Protocol"
	spec: make system/standard/port-spec-head []
	actor: [
		open: func [port [port!]] [
			print 'open
make-scheme [
	name: 'foo
	title: "FOO Protocol"
	spec: make system/standard/port-spec-head []
	actor: [
		open: func [port [port!]] [
			print 'open
		]
		read: func [port [port!]] [
			print 'read
		]
	]
]

f: open foo://bar.baz
read f

hmm, ignore the first duplicate part of the paste

good andreas muchas gracias you know I'm a beginner

There's a typo there .. FOO should be RIF  :)

should a file to be implemented into read for real reading? (how 
to)

into read actor

yes. you can just use normal READ to read from a file within the 
read actor

if you want to keep a file open, you can keep port-local state in 
port/state

OK thanks I'll try my own, anyway is there any distinction if fileport 
is open/closed? after close the information is still open

ie port looks the same open or closed and open? returns true,  more 
the port cannot be deleted/removed currious

What's the current state of RIF?

CLOSE on a foo port will be a no-op, unless you implement a close 
actor.

Same for OPEN?.

graham I've commented it in DB chat , to be honest I thin Carl would 
do it better but I cannot wait more

andreas missunderstanding when f: open %file close f open? f returns 
true

we can't wait for Carl to do everything .. just have to be prepared 
to discard our work if he rewrites it!

exact

you'd write your own 'open? actor

only for open more files at once

my RIF needs to work with double files simoutaneously

Pavel, not for me:

>> f: open %.vimrc 
>> open? f
== true
>> close f
>> open? f
== false

I'll check it

you are right but then f cannot be unset (removed) but I can live 
with it

andreas your open wont do its job I'm sorry

Check this http://sites.google.com/site/rebolish/Home/idx.r

thanks steve for inspiration, may I know why you use actor* and not 
regular actor?

several reasons

Anyway I'm partially succesfull with rif:// scheme, I can open multiople 
files from port: open rif://data/file, I can close multi files with 
clos port, I can write port to-binary "some record". What is difficult 
is to pass argument (number of wanted record) to read actor. it seems 
read acor accept only port. Any hint?

I use copy and copy/part to real several records

I don't use read as actor because of that

It is only different name of function or has it some deeper reason? 
(read malfunction?)

Inside is read/seek/part used of course

deeper reason, you can't add refinement to existing functions (overlapped 
as actors).
I just think copy is more suited to do so (because of /part)

For RIF more suitable names would be PUT/GET as in basic key-value 
stores (memcache f.e.) I can try this convention