World: r3wp

'do-sql is using a trick to determine if the scheme is using a native 
driver (RT's) or a user-defined one. It's testing db-port/handler 
: none means native driver, other value means user-defined. This 
was working ok with the native MySQL driver, could you tell me if 
this test is also ok for a odbc:// driver ? (just open an odbc connection 
in console mode and tell me the value of db-port/handler)

Hey Doc, welcome back.

Hi Terry, back for 5 min only, I was on the road to bed ;-)

Can I just drop the embed module into the latest Cheynne to make 
it work?

Yes, it should work (IIRC, you have to comment all other modules, 
see the doc in the embed-demo.r sample).

mod-embed.r

Ok.. cool.

It's working great by the way.

If you have 3 minutes left, can you explain the shared space between 
cheyenne and uniserve please.

Which one ? uniserve/shared ?

Uniserve is just the underlying network layer for Cheyenne.

You once mentioned the need to use the 'shared' something or other 
for communication between uniserve modules and cheyenne.

It also provides the IPC support.

International Political Corruption?

If only...I would be a rich man ;-). Inter Process Communication

:)

Actually, i have a response from a web page pushing data to a uniserve 
service.. so kinda close.. just wondering if there's a preferred 
method.

One last thing.. how do you feel about incorporating cheyenne into 
a GPL product?

Does the uniserve service share the same REBOL VM than Cheyenne (or 
are they running on 2 different processes ?)

It was two, then I dropped the other and it worked .. woohoo.

Cheyenne is BSD, don't know how it can fit in a GPL product, but 
I guess there's no problem doing that (at least for me).

Ill take that last sentence as your license ;)

Check out my natural language URLs if you get a chance.. in the Atom 
chat group... running on Cheyenne

;-) Sure, I'll try it.

>> p: open odbc://remr
>> db-port: first p
>> probe db-port/handler
none
== none
>>

thanks, so that's not the cause of the issue. You need to probe or 
log the raw output of the following snip of code in %handlers/RSP.r 
('do-sql function) :

any [
	insert port data
	copy port
]

Ok.  I'll try that tonight.

Working at present :(

If the output is ok, it's an issue with Cheyenne, else, it's an issue 
with encapped odbc.

Going to sleep, will be back this weekend.

Thanks Doc

Nenad, how do I set the mime type for delivering up a Flash binary?

er.. ok.. found it.. h-store req/out/headers 'Content-Type "text/html"

however... is there a simple way to change the mime-type of the on-response 
fuction "on the fly" 

the default on-response function is set to "text'/html" when is this 
fired?

(embed module)

Do i need to catch this and inject into the on-response function 
before processing the post data etc?

Ok.. this seems to work.. kinda.. 

	on-response: func [req params svc][	

  ;-- this callback is useful to mutualize the HTTP response settings.
		
		thetarget: copy req/in/target
		print join "target: " thetarget
			either found? find thetarget "." [
			mimetype: parse thetarget "."
			
			if (last mimetype) = "swf"[
			print "is a flash file"
				req/out/code: 200

    h-store req/out/headers 'Content-Type "application/x-shockwave-flash"
				]
			][
		print "is text/html" 
		req/out/code: 200
		h-store req/out/headers 'Content-Type "text/html"
		]
	]

The flash movie is getting to the page with the proper mime-type 
and <object> tag.. but it's not firing? 
Im reading the flash movie using  read/binary  ??

I guess they don't call it "the bleeding edge" for nothing.

Ok.. reading binary doesn't seem to work with .swf

Worked out the other issue.. Flash requires crossdomain.xml file 
to be delivered up by Cheyenne when running Flash that uses xml.Socket 
(like RASH).
Butt it's working well now.. and very cool. 

Works like this.. I run my local copy of Framewerks with embedded 
Cheyenne server, and park the GUI on any server (always accessible, 
single point of bug fixing etc.) for all to use.. currently it's 
here  http://kommonwealth.com/exper/gui.html


Now, it wont work for you 'cuz you're not running framewerks.. but 
if you were..  you could type into the box "codes" and it would open 
the RASH code file, on your desktop, using your favorite text editor. 
  

But wait.. there's more... 

In my local code.txt file i have the following line

PnG "testing" ][bout: {<pre>ok this works</pre>} makeXML ['DISPLAY 
'MSG "testing works here"]]


So when I open another browser, and point it to http://localhost/
testing  that line is fired (more on all this later).. 

Which does two things.. it outputs "ok this woks" to this second 
localhost page .. BUT (and this is the cool part)

it sends the "testing works here" into the panel on the first kommonwealth 
page. 

In other words, Im able to PUSH data to the remote page at ANY TIME.. 
  this will make for the ultimate in portal pages. 

And.. if that's not enough, Im able to pass messages to the DOM via 
javascript to the kommonwealth page as well. 

Allowing things like sliding in panels.. fading div elements moving 
images.. whatever.


So.. remote page can manipulate my computer.. run apps, do any Rebol, 
reboot .. whatever.. and the local desktop can manipulate a remote 
web page.

Finally.

So.. imagine this as a personal server. One on your IPOD, one at 
home, one at work.. all synced up.. where mine is able to communicate 
with yours, and vice-versa.

Add in some S3 for secured persistent data. (Each unit would could 
load in it's entire DB from S3 on boot up and hold in memory, so 
only the core framewerk could ever be lost or stolen... all nicely 
encrypted too


(Framwerks is currently <1 mb all up, including ATOM, Q, Cheyenne, 
AutoIT(macro software), WINAPI and others)

Forget Ruby on Rails.. this is Rebol on Rockets

Nenad, did some more testing.  Encapped Cheyenne/odbc works under 
XP, and Windows 2003 as vmware.  But when I try it on another virtualized 
windows 2003 ? Xen .. it's not returning the correct data from the 
odbc connection.  Bizarre.

My encapped version of Cheyenne is here http://compkarori.no-ip.biz:8090/Synapse_Web_Portal_Server
In do-sql, it has this ...

					][							;-- RT's drivers
						insert port data
						either flat [
							out: make block! 8
							until [if data: pick port 1 [append out data] data]
							out
						][
							attempt [
								tmp: copy port
								rsp-log tmp
								tmp
							]
						]
					]

retyping -- corrupted by Altme.
This is the only change I made to do-sql in handlers/rsp.r

Nenad.. any thoughts on clustering?

One thing I was considering.. rather than paying for expensive servers, 
like amazon EC2,  to host low usage sites, you could run mulitple 
copies of Cheyenne that would sync up.. and maybe an S3 bucket for 
data.. one at home, one at work etc. .. couple these with dynamicDNS 
so in the event one went down, the other(s) could detect that, and 
update the DNS to take over.  Could do some DNS based load balancing 
if necessary.  If you want to get real crazy.. you could share backup 
servers amongst agreeable Cheyenne users...probably wouldn't host 
e-commerce that way, but wikis / publicly available data would be 
fine.

I would like to see RebService integrated into it. Running RS in 
CGI mode but without the overhead of CGI. So, more like a faked CGI.