r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!Cheyenne] Discussions about the Cheyenne Web Server

Maarten
10-Jun-2007
[1638]
Wrt  commercial support: what are the prices and what is the service 
(perhaps better to discuss this privately unless you can make a marketing 
statement ;-)
Dockimbel
10-Jun-2007
[1639]
I'll contact you privately tomorrow about that.
Maxim
11-Jun-2007
[1640x5]
its now official, I am starting work on the most significant (web 
side) module for cheyenne IMO.   remark engine integration   :-)
I don't know how rsp fits into the picture, but once I have something 
of a remark loadable lib working, I'll try to get others to better 
define how to merge rsp and remark (mainly what rsp can add to remark... 
things like session control maybe).  maybe rsp doesn't even become 
relevant... more details to come as I work out all the parts of this 
endeavor.  btw, this effort is brought up by need... not just hobby 
fun.
btw I use the url encode from graham and it works very well.
I also did an html-encode to allow easier form interaction... does 
anyone find a use for that?
(anyone *else*)
btiffin
11-Jun-2007
[1645]
I'll be in like Flint...
Maxim
11-Jun-2007
[1646x2]
btw... your cheyenne home page should be updated... the main link 
is wayyy old.
that was a message for doc... and sorry if reading it , it sounds 
like an order.. <phew> sooo not intentional...  the download link 
I mean, on the main cheyenne root page... you really should update 
that root page its seems to be like 6 months old now!
Dockimbel
12-Jun-2007
[1648x7]
Max: glad to see you using Cheyenne too. About the home page, yes, 
it's still the old one, that's intentionnal for a couple more weeks, 
I want to reach a 1.0 beta first before putting the new Cheyenne 
out in the wild (that's why I keep the current releases almost confidential). 
Currently I want to focus on development and documentation, and only 
support a small group of early adopters (that's you guys ;-)).
A precision about modules : modules are executed in Cheyenne's main 
process (same process as UniServe and HTTPd service), so modules 
execution has a direct impact on Cheyenne performances. In order 
to obtain the best performances and best scalability, you should 
implement also what is currentle called in UniServe : a "handler". 
A handler in UniServe's context is a module executed in a background 
process, so it's not blocking Cheyenne's main process. A good approach 
might be to implement a module first, then export some of the most 
CPU intensive work in a external bg handler. That's the way CGI and 
RSP support is implemented. For a good example, see %mod-action.r 
and %handlers/CGI.r
If some of you needs to implement handlers now, just ping me here, 
and I'll write some preliminary docs on bg tasks API (quite short 
and simple in fact).
Btw, mod-action provides a general purpose background tasks launcher, 
you could use it for making your first "bg handler". Here's a small 
sample code for implementing a bg task handler called "demo" :

- Add in %httpd.cfg in globals section :

	bind-extern demo to [.dem]

- Add  %handlers/demo.r :

REBOL [
	Title: "DEMO handler"
]

install-module [
	name: 'demo
	
	on-task-received: func [data][	
		data: reduce load data
		wait 0:0:3				; simulates a 3sec long processing
	

  result: reform [		; you have to return the response string in 'result
			<html><body>
				"You're IP is :" data/ip
			</html></body>
		]
	]
]


- Then create a fake %www/test.dem file (with any content, not used 
in this demo handler)

- Launch Cheyenne and try : http://localhost/test.dem
The drawback of using mod-action is that you're tight to mod-action's 
communication dialect. If you need or want to pass other information 
between Cheyenne main process and the bg task handler, you have to 
write your own messaging dialect (quite easy, look at mod-action 
source code).
I know the "install-module" function name is confusing, all the UniServe's 
related function and concept naming will be updated shortly after 
Cheyenne 1.0 to be more simple and less confusing.
Notice one important thing about bg handlers programming, you should 
have exactly the same handler name and handler filename (watch out 
for case-sensitive filesystems).
Terry
12-Jun-2007
[1655]
Hey Doc, thanks..
One thing I was trying with Uniserve years ago went like this.. 
1) A http request is received as usual. (port 80)

2) Depending on the request, Uniserve would launch a process that 
may run for hours (ie: reading a website looking for changes), and 
would occasionally send a message back to the ip address, but on 
a different port (communicates to a flash script on the original 
response page, that in turns manipulates the DOM.)


So, what's the best method to run these small scripts as to not block, 
and close without closing the server. 

I still want to serve up an HTML response, so it's a hybrid of sorts.. 
sends back a page AND runs it as a handler too?
Dockimbel
12-Jun-2007
[1656x2]
UniServe is based on the classic request/response model. You have 
to implement a specific UniServe' service for your specific need 
(like sending a response to another client than the one who sent 
the request). I guess you'll have to maintain in the service's context 
a list of the (browser, flash) connections couples, so there's some 
probabilities that you'll end up write a full custom HTTPd service.
write = writing
Maxim
12-Jun-2007
[1658]
thanks for the info about bg stuff.  right now I will be concentration 
on reformating remark so its a loadable module... a few details make 
it more complex than it could be.  (remark being so flexible).
Terry
12-Jun-2007
[1659]
Doc, I guess my question is, how can I pass a message from a module, 
to a Uniserve service?
Dockimbel
13-Jun-2007
[1660]
uniserve/shared space or a global function.
Terry
13-Jun-2007
[1661]
are there docs on the shared space?
Dockimbel
13-Jun-2007
[1662x2]
no, uniserve/shared is just an object, so you can add whatever you 
want in it using the uniserve/share function.
Cheyenne's RSP API Reference doc updated: http://softinnov.org/tmp/rsp-api.html
Oldes
13-Jun-2007
[1664x2]
isn't the value triger in http protocol (4000) too low?
trigger
Dockimbel
13-Jun-2007
[1666]
Are you talking about the SERVER-PORT's example in the doc ?
Oldes
13-Jun-2007
[1667]
not in doc... it's more related to uniserve
Dockimbel
13-Jun-2007
[1668]
It should be safe to push it higher in order to increase the bandwidth. 
Let me know how it reacts.
Oldes
13-Jun-2007
[1669]
I changed it to value 10240 - the change is not so visible but I 
think it's better as there is not so many on-stream-in calls
Maarten
13-Jun-2007
[1670x2]
An application is just a subdirectory right? And it always requires 
a login?
If so, is there a way to bypass the login>
btiffin
13-Jun-2007
[1672]
Take a look at testapp/login.rsp.  I think you just need to session/content/login?: 
yes and response/redirect/ "/theapp/" to get round a login form.
Dockimbel
13-Jun-2007
[1673x3]
always requires a login

 : no, just remove or comment the 'auth "..." part  in config file.
by default, there's no limitation. If you add the 'auth keyword in 
a web-app definition, you need to be logged in before being able 
to access any resource (that's why you get redirected automatically 
to the login page). Even when 'auth mode is on, you can freely serve 
resources from the /your-web-app/public/ folder.
application = folder (application name) + definition in config file.
Maxim
14-Jun-2007
[1676x3]
knowing there is some some of admin config control panel module, 
is there a way for that control panel to send commands to other modules 
through a web page served from cheyenne?


for example, remark has a custom tags definition which can be changed 
(static & dynamic) .  if a control panel allowed integration to modules, 
I could use it to tell a remark to reload its tag definitions.


is this possible?  or will I have to create some sort of (secret) 
admin page specifically for remark somehow?
otherwise restarting the server is not very cool... maybe the admin 
page allows module restart on the fly?
I am asking,  cause I don't want to have to reload the tag defs at 
each page gen, obviously, that's part of the point of building a 
module in the first place...
MikeL
14-Jun-2007
[1679]
fyi - in R0914 the example for the set-tray is a bit clearer so you 
can add some of the samples or other actions aside from Quit to the 
set tray (right mouse) menu.
Pekr
14-Jun-2007
[1680]
off-topic, but - has anyone thought about abstracting rebol db access 
already? kind of rdbc (odbc, jdbc)? Especially with R3 model coming? 
db.device? - use rif, mysql, sqlite, rebdb, posgress, mssql, etc. 
The question is, if it is possible to support them all via one interface?
Maxim
14-Jun-2007
[1681]
mikeL ahhh that could be an idea  :-)
Dockimbel
14-Jun-2007
[1682x2]
MikeL: good idea, btw, I plan to add a "Reload Config File" option 
soon in this menu.
Re: config control panel: there's some experimental stuff, but it 
still needs a better internal design. If you need to expose some 
parameters, just fill the words: [...] block in your module definition 
and add some config options.  (this is  not yet documented, but by 
looking in mod-static or mod-action, you'll figure out easily how 
to use that feature).
Graham
15-Jun-2007
[1684]
I changed port-id in httpd.r to 8100, but it still serves on port 
80
Pekr
15-Jun-2007
[1685x3]
I once had the same problem
there were twho httpd.r scripts in the distro.
Doc was fixing that IIRC. One of them was experimental and was supposed 
to be removed.