AltME groups: search

SVN r35 :

FIX: improved RSP script error catching involving unset! values.
FIX: fix for a rare case of RSP's response buffer corruption.

I'll update the CureCode server with this new version in a couple 
of hours.

Because I didn't had time to add code to support that feature which 
is probably very low priority currently. I'll probably add a config 
option to better control log storage for the v1.

that's not really a problem - just a question on my side - was just 
wondering, if I have to turn logging-on somewhere, etc.

Hey Doc, how would you deal with an async socket (or .dll) that received 
events allowing realtime updates on a Cheyenne web page?

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.

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

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

There's a good article on installing Freeswitch here http://www.linux-magazine.com/w3/issue/106/Freeswitch.pdf

FreePBX (an GUI for Asterisk) is building an interface to freeswitch, 
but the code is a nightmare

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

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..

Yeah, I'll have Cheyenne create the port to Freeswitch, and you can 
push data to a page via Comet.

I'm running Cheyenne as port 8080 on a machine that also runs IIS. 
I want to get Windows logon which IIS can force for a directory. 
  Anyone doing this already?

Comet requires a connection to stay open, so it looks like this will 
take a Uniserve process for each open connection. That puts a rather 
low limit on the simultaneous clients you can handle with the memory 
of one server

I'd say one Uniserve handler should normally be able to handle several 
tens of requests per second, so even when you would let each client 
browser do a poll request every second, compared to that you loose 
at least an order of magnitude in scalability with Comet

Comet requires a connection to stay open, so it looks like this will 
take a Uniserve process for each open connection.


A Uniserve process (worker process) is not bound to a given client 
connection. Each worker accepts requests from ANY client connection, 
so it can handle hundreds of Comet-like connections with a few worker 
processes as long as each request doesn't take much time. For example, 
if each request takes 50ms, with 10 worker processes, you can handle 
200 req/sec.

Using a busy flag associated with each worker.

The flag is set when a request is assigned to a process and reset 
when the worker answers back.

Hey Doc, any hints / docs on building a Uniserve service that could 
handle what I need?

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. ;()

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

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?

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?

aha, no problem .. how can I read the cookies .. looking at request 
headers I guess (I forgot a little about how exactly cookies are 
doing)

I'm coming to the conclusion that any communication other than via 
HTTP is a waste of time. Sockets suck.

I mean, this low level coding is a pain.

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.

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.

hi, I have a problem about sessions, when I start a session, then 
end it, then restart it, session/active? return false if the file 
is not in same location with the file which is started the session.

I remember a similar issue reported once by a user a few months ago. 
I'm not sure this has been fixed properly or if your issue is exactly 
the same. Anyway with the help of your test scripts, I should be 
able to figure it out.

Please try the test cases I wrote in the email, session/active? gives 
2 different result after restarted a session, if the files are different 
folders

Got it, will give it a quick look now.

thanks a lot

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

Endo, if you don't have SVN installed, I'll send you a zip archive 
by email?

I'll upload a binary version online, just wait a minute...

I downloded 0.9.20, testing in a minute

It doesn't work as a service on my pc. If the other version can work 
as a service, could you please send it to me?

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.

I had a problem to start the recent cheyenne version as a service 
after encapping.
I got always crash.logs that it could not find some files.
After manually copying the files it works.
Can it be that in .cache.efs the new features are not included?

ok, this was not a problem running as a service, but cheyenne.exe 
did not start at all, as it could not find some Uniserve modules.
After adding adding all of them to the cache, it works again.

.cache.efs may have been too old. It is refreshed when you start 
Cheyenne from sources. As a rule of thumb : boot Cheyenne in source 
mode to refresh the encap cache definitions before encapping (especially 
if you did a SVN update).

Doc has said he will fix it .. but I doubt it's a priority.

I could live with loging , it's a somewhat temporary solution .. 
but here the second cheyenne crashes

I used to run several Cheyenne instance on linux server but it was 
a long time ago (v0.9.15 or 16). I didn't do much testing on that 
use case since then.

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 ..

I'll have a look this weekend on this issue to see if I can get a 
quick fix (it wasn't simple last time I've checked, but the cold 
freezing wind blowing out here these days might help my brain be 
better irrigated ;-)).

IIRC, having multiple instances on Windows was significantly harder 
than on UNIX platforms. I'll run a full testing on that issue tomorrow 
to get a better picture.

none of this is urgent.. just few ideas from a happy user :)

improved debugging : on my todo list. I might try to emit the debug 
info to a JS console like Firebug's one or a custom one.

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).

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 :)

so this will  be a good feature to many

I'm not a big fan too, but I can't deny the advantages it gives to 
query an abstracted hierarchical data model instead of the physical 
relational model. The bigger the project, the more gain you get. 
For some cases, you still need to go down to SQL thought.

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...).

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.

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.

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.

-- the .so file missing was another problem but now I saw it still 
works like that. Now that .so it there.. after I restart, if I go 
on webapp af virtual host A first then I see at B that it runs A's 
app-init.r , if I go to the v.h. B birst , then A will report errors 
because it will run B's app-init

Ie. I was seeing a similar bug.

Kaj, about logs that has been fixed a couple months ago, I can only 
suggest you all run latest svn

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.

Hmm, I think that the way I've used "webapps" in my previous msg 
is confusing, I was referring to a "web application" built using 
RSP scripts not the "webapp" keyword used in config file. A web application 
(along with its app-init.r file) is unique. OTOH, a webapp config 
is per virtual host.

Janko, about the app-init code you've uploaded, just a side note 
: you're loading a *lot* of code (libs?) on each RSP request, this 
is surely slowing down each request a lot. You should be loading 
all these libs in 'on-application-start instead. (btw, "simpauth.r" 
is loaded twice)


About local testing, you can use virtual hosts locally too in Windows 
easily. Just add them to C:\Windows\System32\drivers\etc\hosts file. 
Add them all after 127.0.0.1 (but do not use exactly the same domain 
name as the remote ones or you won't be able to access them anymore). 
I use shortcuts of my real domains for locals : softinnov.org => 
si.org, curecode.org => cc.org, etc...

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.

@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, about the app-init code you've uploaded, just a side note 
: you're loading a *lot* of code (libs?) on each RSP request, this 
is surely slowing down each request a lot. You should be loading 
all these libs in 'on-application-start instead.

 or you can add them in the httpd.cfg in a worker-libs block, look 
 in Cheyenne/changelog.txt for 'worker-libs'

HAHA, looks like osx is a time waster, for Dock but for Carl as well 
8-)

Janko: I'll give it a deep look today.

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

Apache already supports web sockets using a python plugin : http://code.google.com/p/pywebsocket

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.

I think that it's simple enough to be implemented in a couple of 
hours including reading the full specifications.

I might give it a try tomorrow. ;-)

Ah, now I got a real motivation to add it. ;-)

Seriously, I'm simply using the Cheyenne I integrated into Syllable 
Server 0.3. Hope to postpone upgrading Cheyenne and other packages 
until I release a complete new Syllable Server

The trick is that web sockets needs a little server support to down/upgrade 
(as you see it) a HTTP connection to a more flexible TCP connection

But once it's a web standard, they can't have the nerve to close 
it off anymore

Will: I would say Comet is obsolete.. Comet is a hack at best.

Though Comet and Ajax can both deliver end-user experiences that 
provide desktop-like functionality and low user-perceived latency, 
only Web Sockets lives up to the promise of providing a native means 
to accurately and efficiently stream events to and from the browser 
with negligible latency. It is by far the most comprehensive solution 
for delivering real-time information over the Web. Not only does 
it provide full asynchronous duplex streaming communication with 
a single TCP/IP connection, but also benefits from few HTTP headers 
and more importantly allows the same message format to be used by 
both the browser and the origin service.

Well, it's a matter of definition. They're very similar, but web 
sockets require the server support

It seems js.io is an alternative to web sockets. If it's true that 
web sockets need native browser support just like the server side, 
Comet will still have a long life

Kaj, "long life" is a relative term.  I suppose it depends on the 
service. If i build a service that lets you access my killer app, 
but say "you need to use Chrome" then 'long life'  may be irrelevant.

The point is that there can be no killer app targeting just a few 
percent of the market

Still, I'm now considering the same as you. If I bundle Chrome with 
Syllable, by the time I am progressing with a few web apps, web sockets 
may have penetrated far enough to not bother with Comet

I've got this really odd situation ... I have Cheyenne and the rebol 
micro web server both running.  Cheyenne is on 8002, and MWS on 8001.
Both share the www directory.

at times I access a file and I get a 404 from Cheyenne but the MWS 
can find the file!

Looks like my application is writing files to a hidden directory 
somewhere which the MWS can see, but Cheyenne can't see.

So, not a Cheyenne issue ...

Found a cool example for future Cheyenne web sockets : http://www.onlinegames.com/basketball/

Did you created a group Dock ? perhaps i can beat you

SVN: Can someone give me a short note how to best get the SVN version 
into a "production environment"? Is it one file I can just run on 
the server? Or do I need to build it myself somehow?

Just use a svn client to download the repository, run the source 
version once, and then encap it.

Using Cheyenne and websockets as a backend to Flash, Silverlight 
etc would have it's merits as well.

I can envision a day when everything will have an "always on" connection 
with everything else that is important.. probably via websockets. 
 ie: my email, chats, voicemails pushed to me wherever i am, and 
on whatever device. The ability to do this is nothing new (SOAP, 
XML-RPC etc), but what is missing is a homogenous catalyst... the 
webserver seems the most likely candidate, as they are the de-facto 
interface to the world's DBs. This is my vision for Cheyenne, that 
of an Uber-server.

I looked at Node a few days ago, interesting choice to see JS at 
server-side. I guess that the included 8k lines of C code help a 
lot having a decent speed. ;-)

Is there a dummies for web sockets to explain what this does?

It's the evolutionary endpoint of Comet. It throws in special server 
and client support to enable them to keep an open, stateful connection, 
by switching an HTTP connection to what is effectively a lower level 
TCP connection