AltME groups: search

I had a look on chat and there doesn't seem to be anything there 
....

read returns binary if it can't convert the content to string (ie. 
content-type is not text/* and charset is not UTF-8.) this was a 
quick addition after the unicode changes, and needs much more work.

i don't remember when that can happen (i think you should always 
get something if you did a successfull request).

make-http-request is called from the read or write operations. eg. 
write [head %index.html] will make a HEAD request etc.

ah, aws. there is no direct way currently. that's what you get when 
people abuse http. :-) it should not be difficult though to allow 
the user to specify a callback for aws-like signatures etc.

or, just define a aws:// scheme inside the same module as http:// 
so that 99% of the code is reused.

And now it's a module and hidden !

now, in principle, prot-http.r should be a module. so, they can be 
imported from there, in principle. where the module is i don't know 
(this was much after i worked on this), i guess inside system/something 
, like system/modules or something like that.

it is possible... it's not like this was greatly tested (back then, 
not many people volunteered to test...), and it was written for a 
very different R3...

one of the things i wanted to do, but never got to, was to parse 
the output of R3's trace, and then show you a step-by-step code execution 
like in debuggers.

Well, this has been useful... we need to test http a lot more ...

it appears to me that if all the properties of the header was kept 
as strings.
then we could construct back the header's response with 
>>enline form headers
(no need to make a foreach anymore)

Gabriele, I didn't modify the .r, Carl did. I'm working on it now 
though. Pardon my memory lapse, but could you post a url to RLP?

Documentation in the code itself using comments, and you structure 
the code for human reading. To any programmer of a language that 
is designed for readability - like REBOL - reading the flow of the 
code is like reading a story. You can understand it immediately.


Reading a literate programming document is like reading a manual 
though, so unless it has story or essay structure it will be difficult 
to understand. Reading the code generated by literate programming 
is like reading a stack of 3.5 index cards that were going to be 
used as research for a story or essay, but were instead just taped 
together at random. The overall structure of the code and every hint 
of the author's intentions are lost.

Looks like everything is opened in binary mode as there are no refinements 
yet to 'open.


So, to implement a line oriented protocol like pop, do we read until 
we get a CRLF pair?

There won't be a string-mode refinement to open.

so used to doing read/lines on a text file

READ is going to have a /text refinement, but not OPEN.

I'm sure there was a reason Graham, or I just forgot, or...

sorry I should have put a bit more meat in my message... this doesn't 
apply to this specific page but to all of REBOL documentation (especially 
R3).  


There doesn't seem to be anyone interested in taking charge of the 
documentation.


AFAICT, I'm not sure people realize that Carl does expect the community 
to be a big player in the documentation. 


this is more a constatation than criticism.  I don't know how it 
plays out in Open source language communities, but it seems to me 
that there is always a little gang which ends up being the documentation 
krew... seems we lack this fiber in our community.

Graham, a scheme less guy

but a few of us could contribute to schemes... a few of us have actually 
written schemes... there also was a great tutorial on rebol forces 
about schemes.   maybe that could be used as the basis for this page.

Note, I referenced a R3 page on schemes

This is hereby declared a R2 free zone

I've had a go at this the simplest of schemes and can't get it working 
... 

http://rebol.wik.is/Rebol3/Schemes/Daytime

I try this

read daytime://time-a.nist.gov

yes but your actors (open and/or read) must create a tcp port thru 
the host

a scheme is only a wrapper above a tcp connection

So you have to do a open tcp://host somewhere in your code

make-scheme [
	name: 'daytime
	title: "Daytime Protocol"
	awake: func [event /local port] [
		print ["=== Client event:" event/type]
		port: event/port
		switch event/type [
			lookup [
				print "DNS lookup"
				open port
			]
			connect [
				print "connected" 
				read port
			]
			read [
				close port
				return true ; quits the awake
			]
		]
		false
	]
	actor: [
		;open: func [port [port!]][port]
		read: func [
			port [port!] /local con
		][
			con: open rejoin [tcp:// port/spec/host ":13"]
			con/awake: :awake
			wait con
			to-string con/data
		]
	]
]

probe read daytime://time-a.nist.gov

=== Client event: lookup
DNS lookup
=== Client event: connect
connected
=== Client event: read
{
55203 10-01-07 07:51:23 00 0 0 282.6 UTC(NIST) *
}

you may add a timeout inside the wait.

(graham's link above is not complete. there are a few pieces missing, 
and they are missing because the code, even tough it works, is crap 
:)

I've logged onto r3 chat a few times .. seems dead to me.

It is also quite hard to cut and paste as the console doesn't support 
it ..except as a dos console

If you want to suggest a plan for better console, please do.

It would not require much on the reblib side to support a console 
-- most of the code is on the host side.

R2 could be used... but, I had "imagined" there were better packages 
that we could use and get a full featured console.

Is that the most practical?  What ever happened to operating systems 
that provide a real console lib?

Certainly, we can use our 1998ish console code to start. But, seems 
a bit backward.

writing a scheme in one line ... nope

and what about a graphic console (with gobs) ?

Of course, if that's all you really need, then just write a do-clip 
function.

so, if you want to read the examples on a web page ( usuaally placed 
on the left ) and have an maximized console open .. you can't see 
both

schemes would be a nice place to start .... we need to get smtp, 
and pop done.

Graham, perfect for a third party to do (and has been for about a 
year).

Gab succeeded, but came up with a few questions on buffering.

Throw in a few example schemes like finger or whois.

So mean Graham, i wrote the virtual-block scheme but it"s not a protocol

We will need FTP. That is going to be a pain, but someone has to 
do it.

Anyway, I agree with this as a priority because it allows greater 
concurrent contribution to R3 base code.

Is that if i map a port at system/ports/output, I can redirect all 
the output (print, probe etc...) ?

If you're working with a line oriented protcol .. do you save the 
buffer to your own buffer and work on it line by line ( deline ) 
?

There's many ppl out there, who will want to try REBOL as a tool, 
and have ABSOLUTLY NO intention into coding some infrastructure things 
themselves. So - we can say such things as "do it yourself" in a 
community cooperative manner here, but let's not dare to present 
such opinions publicly ...

I hope it is obvious too ... but it surely was not obvious in R2 
days. We claimed being a glue, yet the only option to interface REBOL 
was sockets/files (free versions)

This is not a criticue, this is a raised eyebrow ... I think that 
we are on very good route - Extensions + Host ... and we will surely 
get there.

I guess there needs to be a formal limit to what RT does and what 
community should do. It can't be expected that RT would maintain 
console support on an obscure OS. OTOH you might expect HTTP to work 
as a result of RT work or someone close to RT.

Don't think there is anything but a task list.

I'm also unclear as to the license behind community contributed stuff. 
 Say Anton spends a couple of weeks doing an ftp scheme ... under 
what license should it be publshed as ?

this is now declared a GPL free zone ... thanks for cooperating.

but based on this, i have also hooked up libreadline into the r3 
hostkit, in a very basic way

Gabriele, can WeTan get posted to DevBase? There is an area for community 
projects. You could make a folder for your MD3 stuff.

it's still a quite rough integration as e.g. signals (esc, C-c) are 
not yet handled properly

Since the network protocols are asynchronous, it seems that we should 
have a common way to supply a callback to the network resource being 
requested ...

so, if we read a page, we supply a call back to the 'read so that 
our callback is passed the data when it is received....

Just thinking we need a higher level interface to the network protocols 
to exploit their async nature.

what I mean is that, like face/feel, the handler is a low-level set 
of functions which should callback to application hooks based on 
events.

maybe, if it had an event name parameter.  a bit like the event action. 
 but the scheme handler still needs to exist, its the place where 
logical events are determined.

maybe supply a block .. where the first is the one you want used 
on success, and the other is an error handler

I'd rather it be just a function with error events instead.

but the problem with this is that with a single callback, it gets 
hard to tailor your stuff, cause everything has to happen in a single 
function.  I'd rather have named callbacks.

but each scheme will have its own  callbacks.  some schemes might 
support headers, others not... for example, in my http rss reader, 
I had a callback for the file size.  if it was too large, I'd refuse 
the rest of the read and close the port...

yes, but if ports had a way to define callbacks, they would be passed 
on in some way by port using functions.


for example, a codec, would just be a callback which converts the 
stream or returns parameters to tell the port it needs more data 
before it can convert a chunk of input.

There might be a /with option for READ, which supports additional 
options in an options block, but there won't be any other options 
outside of that block. READ is a low-level function, and won't have 
more refinements.

bsd is fine for the license, or mit, one day i'll release it properly 
and attach a license. :P

I've been reading some more of the docs .. and it says that the lookup 
phase in the awake handler is called when the name is resolved with 
a dns lookup .. but that phase is not used when the url uses an ip 
address.  But then I see some demo code using IP addresses ( the 
ping pong server ) where the open port is in the lookup event ...

the weird thing is that you need to perform 2 OPEN when the ip need 
a translation.
A little disturbing...

client: open tcp://127.0.0.1:8080

this returns a port

It's clearly explain in the link you pointed.

Note B

OPEN is called twice. It is moded. The mode is determined by the 
existence of the IP address. If the IP address is not known, the 
LOOKUP happens, otherwise the CONNECT happens. This also means that 
if you do an OPEN of a port where you provide the IP address, no 
lookup is done; you skip directly to CONNECT. If it is necessary 
to determine if the IP address is known (a rare situation), use QUERY 
-- which can be called at any time and is very fast.

only if a dns translation is requested

in this example, the lookup event is not fired. So it''s a bad example

seems not ...

parse "a b c" [ "a" "b" "c" ] => false

It was discussed maybe half a year ago. Don't remember where; there 
are so many possible places

Ok, this is pretty buggy and doesn't seem to send a well formed email 
... not sure why

http://rebol.wik.is/Rebol3/Schemes/Smtp

Anyway I've posted it for discussion, and to allow the rebol optimizer 
have a look ....

There are quite a few issues with it.

As soon as I connect the server sends me a "220" I can only get that 
by sending the EHLO.
Which triggers me to send another EHLO :(

i think you can fix the duplicate EHLO by doing a simple "read client" 
instead of the write

that should re-schedule the port, so that it next awakes with a read 
event

but is that really a burden to send by default an EHLO ?

give it a go ...

sever sends me a bye

I mean I open the port and do a read .. and off goes my email

the strange was rather a remark about the script not working for 
me

if i add a wait 1 after the wait port/state/connection, it's working

gets me to a script error, at least :)

Well, if I do a read in the connect event, I get a 221 response from 
the server

going to try writing a NOOP

waiting for a EHLO ? ahah

still triggers a 221 from the server

so that you can send a block of messages ....