AltME groups: search

(and yeah you will say to me but why you don't do your solution os-commerce 
like based in rebol ?)

hum the amount of  capabilities in a e-shop web site clients are 
used to see now in days  are big...

Stat tools,  catalog edition, shiping, card. And then the hosting 
solution simply doesn't know about rebol so if it's not apache/php/mysql 
or apache/java/mysql  you are fried unless you have full access to 
the hosting solution and you are able to install what ever you want....(cheyenne!/rebol/mysql-protocol 
etc...)

my company has a protocol, the admin just follow the protocol and 
leave the serious issue to me. they said "REBOL is not in the list 
that they should maintain"

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.

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

ooops ...

19/9-23:06:04.537-## Error in [OS-API] : OpenSCManager failed : Access 
is denied. !
19/9-23:06:04.539-[boot] Cmdline args : -vvv
19/9-23:06:04.540-[boot] Processed    : [verbosity 4]
19/9-23:06:04.541-[boot] Boot flags   : [no-screen verbose]
19/9-23:06:04.542-[boot] Data folder  : %./
19/9-23:06:04.545-[uniserve] Async Protocol FastCGI loaded
19/9-23:06:04.546-[uniserve] Async Protocol SMTP loaded
19/9-23:06:04.577-## Error in [dig] : DNS server not found !

Correcting myself about my claim regarding CRLF not sent by REBOL 
built-in protocols : REBOL does send CRLF even if 'newline if used 
as line terminator. A conversion is applied and it becomes CRLF once 
inserted in the port. This automatic conversion (LF=>CRLF) is OS 
independent and is triggered by /lines refinement used on OPEN native 
in root-protocol/open-proto. AFAICT, this behaviour is not documented 
explicitely anywhere. I can just find a few mentions about such conversion 
here : http://www.rebol.com/docs/core23/rebolcore-12.html, but it 
looks like it's related to FTP scheme only (while in fact being the 
default for all schemes relying on OPEN-PROTO).

SVN r30 :


FEAT: MTA engine refactored, jobs are split in sub-tasks allowing 
more reliable and cleaner code.
FEAT: Default SMTP delay reduced to 5mn.

FEAT: MTA queue can now be saved on disk when server is restarted 
(persist [mail-queue])

FEAT: added native DNS async wrapper for UniServe (protocols/DNS.r)

FEAT: replaced blocking DNS calls for MX domain resolution by async 
DNS calls.

FEAT: 'on-mx event in DIG protocol now returns a block of all the 
declared MX.

FEAT: now all MX will be tried in right order by the MTA if connexion 
fails.
FEAT: improved SMTP logs by prefixing with a SMTP session ID.

FEAT: upload data in HTTPd limited to 2GB (max supported by integer! 
type)

FEAT: 'email-info? RSP function return data format improved (see 
email.rsp header)

FIX: email.rsp minor bugs fixed and From: field added.
FIX: minor fixes in email.r library.

FIX: now uni-engine's logging level is also set by 'set-verbose function.

Could try the async http protocol but it's currently written for 
https

I would build a new "protocol" module for the underlying UniServe 
to achieve that.

From what I've understood of your need, you should look into the 
"Protocol API" part (and not the "Service API" part).

So /Service acts as a receiving port vs connecting to a port via 
/Protocol

Yes. /Protocol = client side.

Cheyenne could get some good press by creating a protocol to handles 
ws://

Seriously, if you jump on the websocket server protocol, you can 
quickly promote Cheyenne to the masses.. but if you wait, you'll 
lose the window of opportunity.

I imagine you could build a web socket protocol with Cheyenne in 
a few hours.. would take me a week

the protocol, by the way, is ws:// or wss:// for SSL

I'm having a quick look at the ws protocol, just curious to see how 
it has been designed.

The problem I've always had with Cheyene and Uniserve services was 
the 'disconnect' between the two.. ie: having a uniserve 'socket' 
connect with an 'http' connection and vice-versa.  The ws:// protocol 
was what i was looking for.. the best of both worlds. Deliver some 
hypertext, then push data to javascript in the browser.

Yeah, it seems like a no-brainer for Cheyenne to easily implement 
this new protocol... at least for a Cheyenne guru.

FYI: I've implemented the web socket protocol in Cheyenne last night 
(not released yet) but I still need to figure out how to properly 
interface incoming data frames with the RSP engine.

Once connected, all the web socket traffic is directed to the starting 
RSP script, where you can implement your own application specific 
protocol and action dispatching while benefiting from the RSP webapps 
features (like the webapp filesystem structure with private/public 
folders).

Needs to be in a forever loop somewhere. I'm guessing a service (or 
protocol.. can't remember which)
so that you can connect and to this.. 

forever [

do %somehandler.r

]

where somehandler.r could manage the connections? no?

but wouldn't it just be standard on-connected , on-received  protocol 
handlers anyway?

Btw, the Internet Draft defining the web socket protocol (http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54) 
is really badly written. In particular, algorithm descriptions are 
incredibly obfuscated. On the design side, a packet-oriented protocol 
not sending packet length (for text frames), rather relying on begin/end 
markers, is a surprizing choice to me.

On the design side, a packet-oriented protocol not sending packet 
length (for text frames), rather relying on begin/end markers, is 
a surprizing choice to me.
 

I think this is pretty much standard.. 
From an Xml sockets in Flash article


send() - This method allows you to send a string of characters through 
the socket connection. While the string is usually in XML format 
it does not have to be. This string can either be constructed using 
the XML object within Flash, or manually if size permits. Flash will 
also automatically append the terminating null character for you.

Looks like I'm not the only one ranting about web sockets protocol 
specifications : http://blogs.webtide.com/gregw/entry/how_to_improve_websocket

You'd need to implement the client side protocol in REBOL

Doc.. any more thoughts on the ws:// protocol system? As it sits 
now, it's a glorified AJAX call.

without task!, Doc can't start moving Cheyenne (our premium product) 
to R3. He recently added early support for websockets protocol ....

Futher processing

 can be done in RSP scripts in worker process, that's what they are 
 meant for. If you need to connect to a third-party server, arguments 
 passing depends on the communication protocol required.

in the chat protocol, if a user close the browser window, will it 
signal "user quits the room" ? I should try...

Web socket protocol is fully described here : http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol


Quick protocol overview : http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-68#section-1.2

standard protocol for sockets : JSON.

Btw, keep in mind that defining a "standard" protocol above web sockets 
goes against its primary purpose : provide a general purpose packet-oriented 
communication channel. It would be like defining a "standard" protocol 
above TCP.


For practical usage with JS clients, JSON data format is the way 
to go. Don't forget that the web socket implementation in Cheyenne 
is partial, only TEXT frames are supported currently. I could add 
the binary support also, but I don't have a need for that for now. 
If someone has a *real* need for that, let me know.

Right, this requires NTLM to authenticate users. I've hacked once 
a RSP script for authenticating LAN users on a W2k domain (for a 
customer). It didn't worked fully from scratch, as my ntlm:// scheme 
needs some improvements to better deal with Windows security model 
(I had to make some customer specific hacks in the protocol stream). 
Unfortunately, these hacks seems lost, I can't find the script anymore 
in my archives after a quick look.

I'd gather that it's not much different from using the mysql-protocol.r 
script under normal circumstances.

Does mysql-protocol.r need to be called in each rsp page that you 
create? I see that Cheyenne has database configuaration properties 
in httpd.cfg is mysql-protocol.r already implemented in Cheyenne? 
Sorry for such basic questions but the documentation is fairly limited.

Thanks Henrik I'll study up more on app-init. It just appears that 
mysql-protocol.r is being loaded by cheyenne on startup because of 
the way database access gets defined in the cfg file.

In addition to Henrik's answers, database access can be used in two 
ways, either "manually", opening and closing connection yourself 
from a CGI or RSP script (READ mysql:// prefered in that case), or 
by relying on the RSP webapp API to manage persistent connections 
(see DO-SQL function in RSP API doc).


In both cases, you need to load mysql-protocol.r. The best place 
for that is in the config file in GLOBALS section, just add :

worker-libs [
    %<path-to-mysql-file>/mysql-protocol.r
]


Usually, I define a %libs/ sub-folder in Cheyenne's folder and store 
there all the libraries used by all my RSP or CGI scripts.

The following sqlite driver should work with DO-SQL : http://www.rebol.org/view-script.r?script=techfell-protocol.r

Your SMTP server sends two 220 greetings lines instead of one which 
doesn't comply with RFC2821, so it is rejected by Cheyenne's MTA 
as an error. I'll improve the MTA to accept such protocol deviations.

In order to use the mysql protocol, you have to include it as a worker-lib, 
I guess.

Don't use odbc - Cheyenne doesn't support it with the default build. 
Use the standalone mysql protocol linked above.

Don't mix the ODBC- with the mySQL-driver. Doc's mySQL-protocol works 
with all versions of Rebol(2). You use it thru the mysql://-scheme.

Redis protocol spec.. very simple  http://code.google.com/p/redis/wiki/ProtocolSpecification

Now all we need is a Cheyenne protocol :)

is there a ws:// protocol implementation for R2? How do I connect 
to a server and use websocket without a browser?

http://www.whatwg.org/specs/web-socket-protocol/


Doesn't look very difficult .. if you need it, start a bounty for 
it

Now Ladislav is the master here having written the beer protocol 
which multiplexes different frames over tcp .. so I'm sure he could 
do this if there are any difficulties.

So, we could use this to send email instead of RSP script?  Just 
have to upload attachements base 64 encoded still I guess as it is 
still a text protocol

Graham: websocket is just an evolution of the HTTP protocol, it's 
not TCP, you can't contact a SMTP server from a browser directly 
if this is what you have in mind.

I would just have to use an ws:// protocol ... yet to be written

I wrote a very simple ws client protocol, http://rebolforum.com/index.cgi?f=printtopic&topicnumber=47

yes when I paste it to the forum, all formatting goes out..
in http protocol scheme, pick takes just one argument, port.

I put my ws protocol here http://www.moldibi.com/download/ws.txt

ws protocol works,
run the chat server (see the post on the forum)
p: open ws://localhost/chat
insert p "hello"
pick p 1
== "hello"
insert p "/nick endo"
pick p 1
== "server: you known as endo"

ws protocol is event based in its specification, so made it as no-wait. 
then and event based protocol can be built on this.

HTTP protocol is one of the simpliest Internet protocol to support, 
nothing that a skilled developer like you can't handle. :-) Anyway, 
I would be pleased to answer questions, as my free time permits.

A FastCGI server protocol implementation in R3.

Both are supported by the protocol, afaik, depending on the particular 
server settings.

Additional Notes:

Due to browser security restrictions, most "Ajax" requests are subject 
to the same origin policy; the request can not successfully retrieve 
data from a different domain, subdomain, or protocol.

Script and JSONP requests are not subject to the same origin policy 
restrictions.

I presume it's okay to start up cheyenne then load up my modified 
http protocol ?

Sure, you can load your custom HTTP protocol from your RSP code, 
or better, using the new "worker-libs" config block.

OTOH, that means each worker needs to load this ... might be easier 
for me to re-encap as the default http protocol

my-http is nice though. i wish there would be a guide for all these 
protocol extensions.. there are a couple of half-baked versions of 
them... :/

Protocol extensions: right, they could have been listed somewhere 
on REBOL web sites.

pff.. my-http is not really transparent...

>> do http://www.rebol.org/download-a-script.r?script-name=my-http.r

connecting to: www.rebol.orgScript: "patched HTTP/HTTPS protocol 
with cookies support" (18-Aug-2006)
== none
>> trace/net on
>> read http://localhost:8080/testapp/login.rsp

URL Parse: none none localhost none testapp/ login.rsp** Script Error: 
querying has no value
** Near: http-command: either querying ["HEAD"] ["GET"]

The newer websocket RFC is much better written and more exhaustive 
than the previous versions. The protocol has also nicely improved 
fixing the remaining security issues.

As long as clients use the standard websockets protocol, they will 
work with Cheyenne.

Carl once admitted that is was possible but not "enabled".   AFAIK, 
he never told anyone the trick.  maybe its unstable and didn't want 
to put time on it.


theoretically, one could build an https server protocol in R2... 
the encryption algorithms are all there AFAIK in /pro licenses.  
its just knowing the handshaking protocols and all that... I look 
briefly at the RFC once and its not "obvious" to implement... at 
least not for the bg I have.

How do you get the source to the http protocol as documented here 
http://www.rebol.net/docs/prot-http.html

must initiate the path var to get a response from the server:
read [ scheme: 'http path: host: "www.rebol.com" method: 'head]

** Access error: protocol error: "Server error: HTTP/1.1 400 Bad 
Request"

Ok, we seem to have some basic information now on how to use the 
http protocol :)

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?

The daytime:// protocol must be the very easiest to implement ... 
how would that be done under R3?

I grabbed stuff from Carl's demos and Gabriele's http protocol

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) *
}

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

rebol []
make-scheme [
	name: 'dns2
	title: "DNS Protocol"
	spec: make system/standard/port-spec-net [port-id: 80]


	awake: funct [event ] [
		print ["=== Client event:" event/type]
		client: event/port
		switch event/type [
			lookup [
				; print "DNS lookup"
				probe query client
				return true
			]
			connect []
		]
	]
	actor: [
		open: func [
			port [port!]
			/local conn
		] [
			if port/state [return port]
			if none? port/spec/host [http-error "Missing host address"]
			; set the port state
			port/state: context [
				state:
				connection:
				error: none
				awake: none ;:port/awake
				close?: no
			]
			; create the tcp port and set it to port/state/connection
			port/state/connection: conn: make port! [
				scheme: 'tcp
				host: port/spec/host
				port-id: port/spec/port-id
				ref: rejoin [tcp:// host ":" port-id]
			]
			conn/awake: :awake
			open conn
			print "port opened ..."
			; return the newly created and open port
			wait conn
			conn
		]
	]
]

open dns2://www.rebol.com

there is no way to know how much packets can be received.
Your protocol has to send this info, if not you're tricked

and the flow up to "buffer USER" will be pretty much the same for 
each protocol that sends and initial welcome message

the other design issue is wether the protocol should be sync or async 
for the user (i.e. the "script")

someone had a link the other day which mentioned that the series 
protocol should be available completely

The only tricks are to see if it has proper TLS support and whether 
it is suceptible to the recently discovered SSL/TLS protocol vulns.

now my ftp scheme is doing what I need .. I can move onto my fax:// 
scheme which uses the ftp protocol but on port 4559

It's a poorly specified protocol that is a lot of work to implement 
...

Great progress ... was able to submit a fax using my new fax:// protocol.

The fax protocol is similar to ftp but uses port 4559, and uses additional 
commands

we can add a series protocol later on

i intend to iterate POP3 until i consider it to be a good example 
for a basic scheme implementation for an "interactive" (lock-step 
request/response) protocol

If anybody wants to start torrent protocol, here's simple *.torrent 
parser: http://box.lebeda.ws/~rebolek/rebol/torrent.r

I could use the .torrent file parser now, even before we start writing 
the protocol, to do file management utilities.

OPEN would assume rebol knows how to decode the binary data downloaded 
by the protocol.. 

can OPEN handle an avi file as we speak?  I don't think so.

Is someone going to write a torrent:// protocol ...or is this torrent 
noise ?  :)

I don't think my r3protocol-fu is high enough to continue much further 
than this parser :) But I may look at it tommorow bit more, to see, 
what it requires to write a protocol.

well, you don't need to write a scheme ... if you can write it as 
tcp, then it can be turned into a scheme and protocol

starting with a torrent protocol is probably not the first thing 
one should tackle!

brian: sorry... you're right (open vs load), but if a protocol/scheme 
exists for torrent, read and write should work on it, just like for 
any other scheme, its part of the point of having this whole architecture... 
no?

this could make a nice protocol  ;-)

http://suicidemachine.org/