AltME groups: search

I took a look at the page source, it seems to simply search the scrollable 
list titled search results, it doesn't appear to go back to the server.

I think it would take a little time to understand what the JavaScript 
is doing.

I've seen the resent updates to comlib, great job Anton ! keep it 
up !, 2006 was crazy i've to switch bands an now im working in a 
unix enviroment, im only migrating bash scripts to rebol :)

Oh wow ! You're back ! I wondered where you went. :)   "switch bands" 
 Do you mean you started work at a new company, which uses only unix 
? Hooray ! So now comlib is needed by one less person ! :)

anton, can this be used to embed MS IE into a view app?

Hopefully, since it is a wrapper for COM, you should be able to do 
anything that COM allows you to do. So the answers to all these types 
of questions are to be found by researching COM land (which I myself 
am not very familiar with).

This is pretty cool news.

If you find an extra second or two, a "Powered by the awesome Cheyenne" 
graphic
would be nice.  Thanks Doc.

Graphics - a target with a lot of arrows in the bullseye? Cheyennes 
where good at that?^^

A single arrow in flight.

the idea being conveyed is how a simpler technology ( arrow) can 
be more nimble in some situations than a more advanced technology 
( guns )

An arrow shot into a gun barrel, like you see in Green Arrow comics 
all the time?

How about a tent ... lightweight website home

I think a tent is pretty close to ideal ...

It's portable and easily setup .. a feature of Cheyenne

and like most websites ..it's a home under construction :)

I don't know, but a "powered by" integrated over the current Cheyenne 
logo would be
fine by me...well that, and a transparent background.

powered by a tent

Hosted in a tent. Good point though.

Linux is like a wigwam?^^

Just a few words to say that thanks to Will, I've managed to fix 
an important issue regarding port leaking in Cheyenne, and we even 
patched Will's server in live without having to reboot Cheyenne (kind 
of open heart surgery). The new release is almost ready, but I'm 
late with the documentation and website update, so I guess that I'll 
make a first release here for the people already using it and make 
a public release on the website with documentation (and logos for 
btiffin ;-)) on wednesday night.

A brand new bugtracker (in RSP) will be online by the end of the 
week, so I'll be able to track more easily and reliably all issues 
regarding Cheyenne and any other of my projects.

The bugtracker will be fully open sourced and will also serve as 
demo of a complete online application done in RSP with a DB backend 
(MySQL currently).

I'd say GREAT! the live patching was a real adrenaline experience 
8-))

about R2, have an ajax app with db calls (ok mysql +query cache enabled) 
, 200 reqs/sec brings a dualG5 2GHz at 80% cpu pretty fast 8-)

now that Cheyenne is ultrastable on heavy traffic, I'm more looking 
forward to a Intel native rebol for os x running on a 8core xserve 
than a R3 version ;-)

still looking forward to a faster R3 version, shouldn't be to hard 
to add machines and distribute task-handlers , and if the main process 
get too busy, put a lighthttpd proxy in front.

you could pretty easly write a mod, you may able to do that with 
mod-rewrite which get called in the url-translate phase

Btw, the encapping system for Cheyenne is a little odd : to be able 
to run it in normal mode and encap mode without changing the source 
code, I wrote a special lib emulating the filesystem but in memory. 
I didn't had time yet to check if Ladislav's Include could do the 
job. My encapping system needs to generate a .encap-fs file, so it 
needs that Cheyenne be run in normal mode at least once. I'll document 
that in a few days.

See Cheyenne/docs/rsp.html for the new RSP API (the doc is half complete, 
I should finish it tomorrow and add a CSS)

Im looking to run my Uniserve service along side of Cheyenne.. using 
a particular port.. but the one last thing i need to do is pass messages 
from the httpd to the service.. will this be trivial?

I also add a general manual for setting up Cheyenne and basic CGI, 
RSP and Session concepts in the next days.

Terry, in my todo-list, I have a generic module for interfacing cheyenne's 
HTTPd with REBOL applications called mod-map-url (or mod-mapping). 
It will map predefined URLs to REBOL objects. Example: http://domain.com/app/show
will call the function ''show from your object 'app. This module 
should cover most of needs if you have to embed Cheyenne in your 
REBOL application. If it doesn't cover your specific needs, you'll 
have to write a specific mod_xyz HTTPd module, which might be a little 
more complex.

Louis: thanks, releasing a new version is like winning a battle (against 
all those evil little details!) ;-).

Yeah, not so much a URL.. but a message.. I want to be able to push 
to the browser.. client logs in, we grab his IP, pass this to the 
rebol script that can push to a receiving JS script.

In any cases, HTTP communications involve a request from the client, 
so it implies an URL...unless your JS is not using HTTP protocol 
?

Um, no.. I wrote a uniserve service to push messages to a flash script 
embedded in the page.. the script then passes the message on to JS

You can use the uniserve's shared space to share data and functions 
between services (anyway you'll have to add a specific module to 
HTTPd to be able to exchange data through the shared space, HTTPd 
is not exposing any function nor callbacks to the shared space, but 
it might be a good idea to add such feature...).

I hacked your HTTPd somewhat to 'intervene' .. just wondering if 
there was a purer method.

flash works great.. did you see the RASH windows demo .. I embed 
that into a page, and push data to it from my uniserve service

The current clean way to extend Cheyenne is to write a mod_xyz module. 
The module specifications are documented in Cheyenne/docs, and your 
have several examples in Cheyenne/mods. I can provide some additionnal 
explainations through this altme channel if needed.

It's not that hard to write one, the hard part is to correctly set 
the execution order for each callback (each module competes with 
all other modules for a given callback event, and you have only 3 
possible positions, 'first, 'normal (middle) and 'last.) The loading 
order of modules in the config file (httpd.cfg) also impact the final 
order of callbacks execution. I plan to move to a much more simplier 
system for Cheyenne 2.0, it will loose some little flexibility, but 
it will be much more easier to write extension modules. But , that's 
long-term, i need first to reach 1.0 ;-).

My plan all along has been to incorporate all of our Rebol tech into 
a single unified system, with Cheyenne as the platform.

Basically, you just need to look at cheyenne.r and add an entry in 
the set-cache block, then add a : do-cache uniserve-path/services/your-service.r 
before calling uniserve/boot.

We also plan, at Softinnov, to release it as debian package. The 
issue here is the dependency on rebol binaries, it's a pity that 
there's no REBOL packages that you can "apt install"...

I prefer the REBOL binary to remain small. I should put a mysql.r 
and cheyenne.r file somewhere on my website and give out the URL, 
so you could just : do http://.../mysql.rto install and run it.

Maarten - Cheyenne part of Core 2.7? Not sure it is OK with Carl, 
especially when RT proposes rebservices (which is a bit different 
concept, but ....)

ok, thanks a lot ...

Cheyenne v0.9.10.0 re-released due to a wrong version of the %uni-engine.r 
file. Sorry for that. Download link: http://softinnov.org/tmp/cheyenne-r09100.zip

of course it is ... well, I hope so :-) If 4RSP works, then it should 
be, no? Wait a min, will try with IE, maybe some FF extension does 
it ...

well, never let pekr in, he will always comlicate situation in a 
negative way :-)

I consider finding bugs as a very positive action ;-)

Ok, after testing a lot with FF, and finding no bug in Cheyenne, 
I just cleared the browser cache and all history info and...it  started 
working flawlessly ! Very odd, but since I've cleared cache and history 
in FF, I can't reproduce the problem...Pekr, could you try that ?

but mods have a special loader, so if you want to reload a changed 
module, you need to unload the previous one and do some internal 
cleanup in Cheyenne. This "unload and cleanup" part need to be implemented 
to be able to reload an active module. OTOH, loading a new module 
could be done right now without any issue (remains untested).

Any chance to integrate RebServices CGI mode in a way that keeps 
RS stuff running? So something like a fake CGI?

Doc, at the moment the best approach is to use RebServices via CGI 
(so that it can be used from behind firewalls & proxies). But CGI 
spawns a new process each time and RebServices isn't FastCGI aware 
at the moment.


Hence my idea, if we can tweak a bit and keep RebService running 
on the server but still use the CGI interface to access it. As Cheyenne 
is all Rebol code I thought it should be simple to integrate RebService 
either into Cheyenne or include a nice interface.

Ok.. Doc.. trying to make a mod called my-mod


In the mod folder i create a file .. my-mod.r  that has this code. 

rebol []

install-HTTPd-extension [
	name: 'my-mod

	order: [
	url-translate first
	]
	
	url-translate: func [svc req conf][	
	probe svc/client/remote-ip
	print "test"
	]
]

I added my-mod.r to the %mods/ [ .... block in cheyenne.r
Doesn't fire?

Terry you need to put a none after print "test"

or a logic

the function need to return a value

Terry, I'll provide some better docs about modules creation and a 
step-by-step example on how to build simple module.

Why not runniong the RSP bugtracker of Cheyenne to track the bug... 
of cheyenne ?
Like this, it's a live and usefull Demo !

Dock said he will use it on softinnov and also release the source 
as a complete rsp example, probaly not yet ready for "beta" 8-)

robert, yes to integrate rebservices as a 'cgi access module' (bridge)

which provides e.g. a persistent connection to sqlite or rebdb etc. 
would 

be nice. could be also used as a starting point for a nice webbased 
admin-concept for sqlite.

Is there a release somewhere that I'm missing and evrybody else *did* 
find?

Didec: I need to finish to CSS code to put the bugtracker online, 
it will take me a few hours of works, so I put it online this  weekend.

I have a new beta with several fixes ready to release. I'll post 
the link here and update the website tomorrow.

With RSP, session support, CGI and mysql:// this is a rebol web app 
framework that most languages can only dream of (productivity wise).

please give me a few minutes to let me post the latest Cheyenne beta 
sources and I'll write a post about how-to make PHP work.

Terry, it seems that's a issue with the way the request pipelining 
and multiplexing is done by some browser. I've plan to fix that this 
weekend.

Brian, I can't reproduce this behaviour on my Windows box whatever 
browser I use. I'll try on a linux box tomorrow morning.

Well.. it's still looking really great.. love the module methods.. 
very clean.
Im going to deciated 2-3 hours a day building mods ;)

doc, I think I'll give this latest version a spin... is it as easy 
as apache to get working?

Alsways do a fast COMMIT ;-) and no nested transactions.

So Nenad, are you considering a more native PHP implemenation to 
increase performance?

Possible to make the PHP handler a module as well?

Pre or post-processing PHP: currently it would require a dedicaded 
mod to achieve that.

Seems like a 'best of both worlds'

Looks my old rsp application needs a few changes to run under this 
version of cheyenne

Is a connection opened somewhere to a sql database?

then, if you're not using RT's DB drivers, you need to load your 
driver somewhere : %misc/rsp-init.r or %www/your-app/app-init.r (if 
you've defined a webapp) are good places to do so.

this is a lot more complicated than the 2005 version :)

so, to send a query to "bugs" ?

re 2005 version: you're don't need to use do-sql if you don't want 
to. You can do it as usual by opening connection, sending query...closing 
connection. do-sql is just a higher level wrapper to save you some 
time.

and there's a query object that holds the result of the do-sql ?

the current rsp-api doc is just an API reference documentation, I'll 
provide a more general explanation about RSP concepts and features 
separately in a few days.

Or, does it just spawn a separate rebol process for it?

Before I think I checked on each page to see if the user was authenticated 
by checking the session.  But it looks like this is now automatic, 
and the user is sent to login page if they access a page and the 
user is not authenticated?

Right, but only if you're inside a web-app container (defined in 
the config file). Otherwise, it's up to you to do the checking.

2- RSP with session context : start a session using SESSION/START 
and keep some data persistant in the session context.

if you're using the odbc:// driver, like all RT's DB drivers, it 
requires a : first db-port to open the connection port, so you have 
to change the do-sql source a little bit (in %handler/RSP.r file), 
in do-sql source :

I'll fix that for next release. It wasn't a priority for me until 
now, because I only use my own DB drivers which API differs a little 
from RT's ones.

Error Code :
			
301

		Description :
			
 script  error ! 
 sql needs a value

		Near :
			
[sql: do-sql 'remr qry 
probe
]

		Where :
			
protected-exec

I'm passing a correct sql string .. tested in console, but I get 
this error.

need to go, will be back in half a hour.

If you close Cheyenne by using the [x] console gadget, a ghost image 
remains in the systray (disappears if you pass you mouse over), f 
you stop your Cheyenne session by using the systray menu, it will 
clean it properly.

give me a few minutes, I've reproduce the error here using RT's mysql 
driver, tracking the cause...

Here's a patched version of do-sql working with /Command DB drivers 
(paste it in %handlers/RSP.r) :

/Command DB API is a de-facto standard. I didn't complied with that 
standard, just because I found it not handy the db-port / command-port 
approach ...so my fault ;-)

Doc, is possible to integrate a different DB backend? I'm using SQLite 
now most of the time. Would be cool to use it with Cheyenne as well.

You can use it freely with Cheyenne. If it has a standard scheme 
interface (like sqlbd://), it may work with 'do-sql, otherwise, it's 
up to you to do the opening/closing part.