• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

AltME groups: search

Help · search scripts · search articles · search mailing list

results summary

worldhits
r4wp4382
r3wp44224
total:48606

results window for this page: [start: 37001 end: 37100]

world-name: r3wp

Group: !Cheyenne ... Discussions about the Cheyenne Web Server [web-public]
Robert:
14-Oct-2009
Doc, I think that the problem lies somehwere in the session terminating. 
It realy looks like session IDs somehow survive and are re-used even 
for a complete new session.
Dockimbel:
14-Oct-2009
Could you make a minimal RSP script that shows the problem and send 
it to me?
Robert:
14-Oct-2009
I'm currently trying to find out how to make it repeatable. It seems 
to only happen somestime (or I don't understand the situation at 
the moment). I add some debug output and will keep an eye on it.
Maxim:
14-Oct-2009
doc, I've got some questions about http.cfg vhost redirection...

www.domain.com:81 [
	redirect 301 "/*" "http://www.domain.net"
]
www.domain.net:81 [
	root-dir %/E/dev/project/my-web/web/www.domain.com
	default %index.rmrk

]


should this work?  cause its not .  I'm still getting a request for 
domain.com and a 404 error.  domain.net works perfectly.   

actually, unless I include a root-dir entry in domain.com config, 
I get an error within cheyenne.
Maxim:
15-Oct-2009
also note, I tried adding the :81 to the redirected domain and it 
didn't seem to change much.
Dockimbel:
15-Oct-2009
I've added your virtual domains definition to my httpd.cfg file, 
added a root-dir to domain.com, added :81 to the redirection URL, 
mapped both domain to localhost, changed domain.net's root-dir to 
%www/testapp and it works ok :

>> read http://www.domain.com:81
connecting to: www.domain.com
connecting to: www.domain.net
== {<html>
<head>
^-<title>Welcome to TestApp web application</title>...
Dockimbel:
15-Oct-2009
and also changed default file to %index.rsp.
Dockimbel:
15-Oct-2009
Those associations could have been hardcoded in each module, but 
BIND gives a more convenient way to define and maintain those associations 
than having to change mod-* source code.
Maxim:
15-Oct-2009
ok cool... I'll add a new directive for remark which is bind-static, 
since it treats static and dynamic files differently.
Maxim:
15-Oct-2009
and use bind for the dynamic mode
Maxim:
15-Oct-2009
I'll probably analyse the RSP handler and mod for proper understanding 
when I get to it.
Maxim:
15-Oct-2009
handlers seem easy enough to setup, but then it opens up a few problems 
for session concurrency, and stuff, which you already know... so 
I want to iron out the whole dynamic remark architecture before tackling 
the performance issue.
Dockimbel:
15-Oct-2009
Sessions (and especially session data synchronization) is the really 
hard part.
Maxim:
15-Oct-2009
I'll be adding session support and integrated forms creation within 
a few days...
Dockimbel:
15-Oct-2009
It would be so much easier to implement and so much more efficient 
if we had multithreading and a way to share data between threads.
Maxim:
15-Oct-2009
sure... I've impleted some purpose built multi-threaded servers in 
python and its quite easy to do.  probably the last real limitation 
in REBOL right now.
Maxim:
15-Oct-2009
I am thinking of building a session server for remark. an uber simple 
multi-tcp port server which implements liquid-net and synchronises 
the remark handlers, in a lazy way.  so unless the users are actually 
calling for pages.... no network traffic occurs between processes.
Maxim:
15-Oct-2009
not as good as mem copies, but should still be effective and scalable.
Maxim:
15-Oct-2009
it has the advantage of freeing the load from the web server so it 
can continue to stream data... and some client work using several 
inter-connected cheyenne servers actually provides good results, 
so I'm optimistic so far  ;-)
Janko:
15-Oct-2009
Doc, I don't know a lot about this subject so sorry if I ask stupid 
questions :) ... could it be made and would cheyenne benefit from 
using IPC like pipes to communicate between processes instead of 
TCP ?
(I used pipes just once so far so I don't know much about them)
Dockimbel:
15-Oct-2009
Pipes implies the same overhead of serializing data to be able to 
exchange it and AFAIK they  cannot be made async in REBOL (polling 
could be used instead but would affect whole server performances). 
Regarding session synchronization, it's the same complexity than 
TCP.
Dockimbel:
15-Oct-2009
'location and 'folder targets are currently unsupported.
Maxim:
15-Oct-2009
ok... with this info I've done a few tests and I see the config files 
allows you to dump pretty much any thing anywhere... is the  'in 
keyword only for the 'do to be recognized within one of the setup 
blocks?
Maxim:
15-Oct-2009
I'd use it to switch debug modes in real-time... and maybe even build 
a small view config/debug pane, if I detect a view version running 
cheyenne.
Maxim:
15-Oct-2009
pekr, remark will be doing this by days end.  specifically, the file 
is parse once, until its saved out and cache is older than source. 
 once processed, normal cheyenne will continue with remark simply 
handling the url-to-file callback.
Maxim:
15-Oct-2009
I want to thank you doc for this exceptional piece of software which 
is cheyenne.


I have been playing around with it for months, on and off, at varying 
levels, and its always been able to cope with my client's and my 
own needs. 

Both in capacity and how flexible it is to adapt and extend to custom 
server requirements.
Pekr:
15-Oct-2009
Max - never mind. If I want to use only Cheyenne, it is not a problem. 
I was thinking around the lines of producing rebol aproach, which 
would be interchangable easily between Apache and Cheyenne, for those 
who can't afford to push their provider to run Cheyenne for them. 
So I thought that following Apache equivalent would be useful. But 
my request surely is not a priority ....

AddHandler rebol-cgi-dispatch .html
Action rebol-cgi-dispatch /cgi-bin/rebol-cgi-dispatch.cgi
Dockimbel:
15-Oct-2009
Max: thanks for the cheering up. :-) I've been also quite satisfied 
by the way Cheyenne evolved, a lot of thanks to patient users who 
report issues and propose fixes or new ideas. I wouldn't have got 
so far without community support!
Robert:
15-Oct-2009
And, I agree it's a very nice piece of software.
Dockimbel:
15-Oct-2009
Only from close friends living in the java world, beyond them, no 
one. I don't expect much from outside REBOL world yet, Cheyenne is 
mainly useful for REBOL programmers. Once it reaches 1.x, Cheyenne 
will have features that would make it more interesting for outsiders 
(like a simple web control panel, web sites and webapp packaging 
in one unique executable, on-demand ready-to-use web application 
loading from our servers: blog, forum, bugtracker,...). I may also 
add a FTP service in a future 1.x version and a lot of other innovating 
new features I have in mind. ;-)
Pekr:
15-Oct-2009
yes, it was supposed to replace Rugby and/or R/Services :-)
Graham:
16-Oct-2009
Pekr and my memory appear to be accurate in this case.
Graham:
16-Oct-2009
and feasible?
Maxim:
17-Oct-2009
Doc, I have a question, and possibly a suggestion based on the answer:


is there a way to tell cheyenne  to HALT when it finds ANY config 
error?


I have been having a lot of problems that where due to the config 
not being ok and me not seeing the (shy) error message... 

currently, cheyenne starts and its in an invalid state ultimately 
doomed to failure and without a clear way to determine what's going 
on when the requests do strange stuff.
Maxim:
17-Oct-2009
although HALTing is mean, it also ensures your server is stable and 
you are forced to fix the config.
Dockimbel:
17-Oct-2009
No way currently, it's a pending issue. The policy to apply is not 
that simple, I may agree on halting when the server starts but how 
to handle the case when you reload config when the server is already 
up and running? I would prefer the server to keep running with the 
previous config file rather than halting. I'd like to handle the 
config error loading case in a consistent way if possible.
Maxim:
17-Oct-2009
I agree, but its mainly on initial start where it bites you the most. 
 cause when you are doing development, you'll edit the config and 
re-start the server anyways to be sure its ok.  right now its easy 
to miss... and I've lost some time debugging issues which where simply 
caused by the config not having been updated according new options 
or changed resources.
Dockimbel:
17-Oct-2009
It restarts the mods (calling mod/on-reload and mod/on-reloaded events) 
but it doesn't reload them from disk.
Will:
17-Oct-2009
can be done easly, source is in your hand , do whatever you want 
with it, sorry I have no time this week and I see no use of timestamps 
in rsp usage, but if I get at least one more same request I will 
add it 8)
Maxim:
17-Oct-2009
it would be very usefull for me... the cache engine may actually 
cache the whole page if some cache keywords are at the top and bottom 
of a page
Will:
17-Oct-2009
you give it a time to live and a block if its expired, the block 
get executed and cache updated
Graham:
18-Oct-2009
and if you run php from the command line?
Janko:
20-Oct-2009
Has anyone made any tool yet that would process cheyennes logs and 
create some usage statistics? even if very simple ones (I removed 
statcounter because I have full https now, but now after I released 
it I would want to see more detailed and realtime stats (basically 
to just see who came in and visited what pages) than google analytics
Janko:
20-Oct-2009
I know for snort but I don't know exactly what it does, I imagined 
it's detects intrusion on many ports (or is it http specific??) so 
it seemed like an owerkill and too complex for what I need ... the 
only port open is 433 , and which only 80 redirects to 433 . Everything 
else is closed by iptables, (on both, 80 and 443 is nginx and behind 
it cehyenne)
Janko:
20-Oct-2009
It's more that I want to observer the http traffic for things I set-up 
.. but a lot of data is in the POST-s ... could I use your regular 
logging and just add the post string ... if it would be longer than 
X chars I would truncate it.
Janko:
20-Oct-2009
ha basically format is the same between nginx and cheyenne so the 
same parser parses cheyenne too (only cheyenne doesn't have referrer)
Janko:
20-Oct-2009
this is good then I can really make it a little more usefull and 
use it on all my projects .. if you need something like it tell me, 
(it's still very simple)
Janko:
20-Oct-2009
It produces this for now (but I will turn it to JSON and then I can 
render it with javascript/html in many ways) days / ip / requests

DAY: 19-Oct-2009
 ....
 VISITOR: 90.157.177.123
   20:22:37 ; GET ; /manage/invoices-sent.rsp ; -
   20:22:37 ; GET ; /manage/sign-in.rsp ; -

   20:22:39 ; POST ; /manage/sign-in.rsp ; https://www.cebelca.biz/manage/sign-in.rsp

   20:22:39 ; GET ; /manage/invoices-sent.rsp ; https://www.cebelca.biz/manage/sign-in.rsp
 VISITOR: 64.233.172.17
   22:11:19 ; GET ; / ; -
 VISITOR: 216.239.50.136
   22:11:21 ; GET ; / ; -
 VISITOR: 74.6.22.173
   23:21:23 ; GET ; /contact.rsp ; -
   23:21:25 ; GET ; /contact.rsp ; -
DAY: 20-Oct-2009
 VISITOR: 93.186.20.135
   00:20:52 ; GET ; / ; -
   00:20:54 ; GET ; / ; -
   ....
Janko:
22-Oct-2009
like with rewrite module in apache .. I would need to map www.url.com/country/city/place 
to get params for example, or somehow get that directly so that some 
rsp would be called for all such folders and I could parse the url 
to get the data
Janko:
22-Oct-2009
much less mess than using another server infront and whole that mess
Will:
22-Oct-2009
Janko, I use:
on-status-code [
	404 "/index.t"
]

that way you intercept all non existent urls and can do what you 
want
Terry:
8-Nov-2009
ie: user clicks a button on a page, send http to Cheyenne.. Cheyenne 
pushes a message via the socket, receives a response, and pushes 
the result back to the page.
Terry:
9-Nov-2009
I've had an idea for Cheyenne.. using it to interface with Freeswitch.. 
there's a vacuum at the moment, and would be a great opportunity
Kaj:
9-Nov-2009
My example is only fourty lines or so and implements a complete command 
service bus; similar to REBOL/Services but much simpler, so JavaScript 
can do it
Terry:
10-Nov-2009
I want to unify communications using Cheyenne (Rebol) as the middleware, 
pulling and pushing info through and to each other

ie: an event message from Freeswitch is processed via xml socket, 
processed, and pushed to a web page via comet / ajax.. and back again..
Terry:
10-Nov-2009
Yeah, I'll have Cheyenne create the port to Freeswitch, and you can 
push data to a page via Comet.
Kaj:
11-Nov-2009
Terry, I've been thinking about it, and it seems to me that Cheyenne 
is not designed to support Comet well
Dockimbel:
11-Nov-2009
The UniServe engine multiplexes client requests between available 
worker processes (and fork new ones if required).
Dockimbel:
11-Nov-2009
The flag is set when a request is assigned to a process and reset 
when the worker answers back.
Dockimbel:
11-Nov-2009
From what I've understood of your need, you should look into the 
"Protocol API" part (and not the "Service API" part).
Terry:
12-Nov-2009
I remember googling a coding problem one time, and found a solution.. 
thought to myself.. "this guy knows the situatioh".. only to realize 
i was my own code i had posted some years earlier. ;()
Terry:
12-Nov-2009
I can open a port, and get the authentication challenge.. i iget 
a content-type: auth/request.. .when i insert into the port "auth 
Cluecon \n\n" i get no reply.. just times out with a timeout error?
Janko:
24-Nov-2009
set-cookie docs don't exist and it says n/a .. does this mean the 
word is not there any more or something else? Do I have to manually 
set http response headers to set cookies?
Robert:
26-Nov-2009
IMO HTTP sucks. Since years people try to make stateless HTPP stateful. 
One just needs a simple socket and than handle everything via a multiplexed 
channel system through this.
Robert:
26-Nov-2009
And, with some tricks everything can be tunneled through port 80 
;-) See Skype.
Dockimbel:
2-Dec-2009
Btw, %private/ folder under a webapp folder is a *special* folder 
that's protected from direct access (you'll get 404 if you try), 
so you can safely store there your libs and support code.
Dockimbel:
15-Dec-2009
2.7.6.3 is the REBOL version. Cheyenne versions are the ones listed 
here :  http://cheyenne-server.org/download.shtml

So, I guess you're probably using v0.9.19. Could you make small RSP 
scripts that exhibit this issue and send them to me by email?
Terry:
15-Dec-2009
Forget that.. download the latest Google Chrome beta and start playing 
with websockets :)
Dockimbel:
16-Dec-2009
Btw, I should use /Face and /Pro terms which are more correct when 
talking about kernel flavours.
Dockimbel:
16-Dec-2009
Right, /Face in service mode can't survive a logoff. It's related 
to how REBOL windows are hooked to screen and lack of correct handling 
of some special events sent by the OS during logoff procedure.
Dockimbel:
18-Dec-2009
The workers depend on task-master service which will change it's 
listening port number if run on port <> 80. So no issue with workers. 
But others services have been added like RConsole, MTA and Logger 
which are not "multi-instances safe" yet.
Janko:
18-Dec-2009
I want to run another webapp on vps where I have site-assistant on. 
but site assistant is written in older version of cheyenne and I 
don't have time to port it to latest right now. that's why I am doing 
this
Janko:
18-Dec-2009
(and this new app is written in latest) .. maybe I should try to 
port it.. can't take taht much time
Janko:
18-Dec-2009
I am using debian .. I will port s-a to new one .. probably won't 
be that many changes, only problem is testing it all again and being 
sure it works ok ..
Janko:
18-Dec-2009
and I was so proud how I solved the problem with nginx :)
Dockimbel:
18-Dec-2009
It needs to be fixed anyway. I, sometimes, also may have needs to 
run different Cheyenne versions on the same production server at 
the same time. Graham also has needs for this, so I think it's time 
to settle this issue once and for all.
Dockimbel:
18-Dec-2009
I'll have some free time from now 'til the beggining of next year 
that I intend to devote mainly to Cheyenne and CureCode, and if time 
permits, on some new frameworks.
Janko:
18-Dec-2009
my wishlist is solving the compression error wher error happens (probably 
harder) and additional option for debug where I could see error output 
in browser like in debug but there would be no debug toolbar (probably 
simple) :))
Janko:
18-Dec-2009
and option to globablly in conf file set compression off maybe
Janko:
18-Dec-2009
and most webdews should if they don't
Dockimbel:
18-Dec-2009
Just for teasing, I've prototyped a Hibernate-like layer for REBOL, 
just read-only for now (only issuing SELECT queries). I'd like to 
push that prototype further to have a complete database abstraction 
layer with object (or blocks) to relational mapping abilities. The 
goal is to kiss goodbye to SQL (for most operations) and be database 
agnostic (the database drivers would have to conform to a specific 
interface, probably the one used by mysql:// and RT db drivers).
Janko:
18-Dec-2009
interesting .. I specifically am otherwise not the ORM fan , but 
so far I am almost the only one I know (except Maxim) and I talked 
to a lot of people about it :)
Maxim:
18-Dec-2009
its just an abstraction layer.  whatever form it takes has advantages 
and disadvantages.
Dockimbel:
18-Dec-2009
Last but not least, I'm also actively working on Cheyenne's Control 
Panel. I'm giving a try to ExtJS for the UI. This would both get 
us a very nice looking Control Panel, and help me optimize Cheyenne 
for AJAX RIA apps (think built-in JSON support, COMET, etc...).
Maxim:
18-Dec-2009
if the ORM objects persist outside the database, you end up with 
a lot of complex state management and it slows down the database 
in real world examples.

its very hard to build the more complex systems outside the DB.


views are an abstraction too, but they are managed within the  DB, 
so there its more optimized.
Dockimbel:
18-Dec-2009
Well, I aim for a thin and simple layer (probably using blocks rather 
than objects). If it became too complex or too slow, I won't push 
it further away.
Maxim:
18-Dec-2009
I build my datasets as named associations rather than relations. 
  there is no relation in the data tables.  a completely generic 
and the most powerfull data model.
Janko:
21-Dec-2009
anyone using cheyenne with webapps / app-init.r and virtualhosts 
at the same time?
Graham:
21-Dec-2009
My recollection is that I had some initializing variables in app-init.r 
but ...they crossed vritual hosts.  So, I removed them and placed 
them into rsp files instead.
Graham:
21-Dec-2009
and other web apps
Will:
21-Dec-2009
Janko, I have many app-init.r and do not see any problem, if you 
sand me your app-init from both virtual host and tell me exacltly 
what is the problem you are seeing, I'll be glad to check that
Janko:
21-Dec-2009
maybe I should download from svn too then. Just some do/global and 
session/add. I tested many times and I can clearly see that whichever 
I visit first after restart becomes "global" and runs also in webapp 
on different v-host. I will try with svn version and report. Maybe 
this problem and problem with logs are related and were both solved 
back then.
Dockimbel:
21-Dec-2009
Janko: webapps are per Cheyenne instance, not per virtual host. What 
is specific to a virtual host : webapp virtual path and other config 
options. I'm not sure to understand how you've configured your (or 
yours?) webapp(s). You can send me your virtual hosts config privately 
so I can see what's your need.
Dockimbel:
21-Dec-2009
About multiple Cheyenne instances running at the same time, I'm finishing 
a new version supporting that feature. It took me more time that 
I thought first due to additional OS specific code required (wasted 
a lot of time on OS X). Still a few minor things to fix, tweak and 
test. It should be available by tomorrow.
Janko:
21-Dec-2009
@Doc: 

- I am not totally sure I correctly understand what you mean about 
webapp. I will need to process and try it some more.

- About code loading on on-page-start : yes I know of that, I am 
using it as dev setup so I know latest code is reloaded each pageload. 
I intend to set it on     on-application start when fully in production 
(But I have to admit the server is bgehaving really fast even with 
this setup all along)
- good catch, I will remove one simpauth.r

- I am aware of hosts file, but so far decided to edit the cfg file 
each time I switch ... which is in retrospect getting a little tiresome 
with more and more apps so I should think of  some naming convention 
for getting to all domains local and do it that way yes

- great for multi instance support . I also already ported site-assistant 
to 0919. it was much less work than I thought.. mostly just few things 
like do -> do/global and some 3 other tricks (no really aplication 
level changes were needed)
Janko:
21-Dec-2009
Thanks for replies :) .. I will think some more about app-init.r 
and what you told and then send you the concrete example
Janko:
21-Dec-2009
and I will recreate multiple virtual hosts on local also before so 
I see how it works here
Janko:
21-Dec-2009
(I sent you email with files and video)
Terry:
22-Dec-2009
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.
Terry:
22-Dec-2009
Some advantages to the ws:// spec

- Seamlessly traverse firewalls and routers
- Allow duly authorized cross-domain communication
- Integrate well with cookie-based authentication
- Integrate with existing HTTP load balancers
- Be compatible with binary data
37001 / 4860612345...369370[371] 372373...483484485486487