World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
| older newer | first last |
| Maarten 10-Jun-2007 [1635] | Wrt session support: nothing stops me (or anyone else) to create a db-session lib that you can use from RSPs. The RSP model is inherently extensible. |
| Dockimbel 10-Jun-2007 [1636] | Sure, you can bypass the internal session engine and use your own ;-). Commercial support on Cheyenne, yes, that's a service we're already offering. |
| Maarten 10-Jun-2007 [1637x2] | OK, I'll try to add some code that works database driven and mail to you. |
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 |
| older newer | first last |