World: r3wp

Do you think you could add keepalive facilities to the service dll, 
where it could monitor the Cheyenne process and restart it if it 
shuts down? That could really help - I have admired that facility 
in recent malware.

My service DLL spawns a new thread to respond to SCM (Service Control 
Manager) messages. The main thread is still the one from Cheyenne, 
if Cheyenne dies, the service dies too. That's an intended feature. 
The SCM has built-in service automatic restart capabilities, you 
just need to properly configure that in service's properties.

That makes much more sense. Does your Cheyenne.exe dynamic-link to 
the dll?

BTW, I recall that Hamachi includes a -srvany parameter that tells 
it to ignore logoff messages and just pay attention to shutdown messages. 
That kind of thing may be doable in REBOL too, with the system port.

Yes, when asked to run in service mode (-s cmdline switch), Cheyenne.exe 
write the service.dll file in its working directory and then use 
load/library.

Is the service.dll file encapped then? By this I mean stored in the 
exe as binary data and written out when necessary.

Yes, it is.

There are times that I wish REBOL had a facility similar to BackOrifice, 
which dynamically linked to libraries stored in exe resources without 
having to extract them. The equivalent in REBOL would be to load/library 
from a binary! value.

That would be a very handy feature. In R3, with thread and good callback 
support, the service DLL would be useless, you could do all in API 
calls from REBOL.

http://www.molebox.com/

Very cool link Tom. Never heard about this one.

I think I have tried this type of program before with Rebol encapped 
programs, and they have not worked for me.

it won't work with encap. encap needs to read the .exe to extract 
the rebol script. there's no way it can do that once you modify it 
in any way. (eg. even changing the program icon can make it fail. 
when changing icons, you have to replace it with one of the exact 
same byte size.)

looks like I'll finally be replacing my webserv.r script soon with 
cheyenne, since I need to build something that will communicate with 
my sourcecode service. :-) looking forward to 1.0.

will there be a VID based config UI for it?

Sourcecode service ? Sounds interesting :-)

VID based config : it's a planned feature, but I need first to finish 
the web-based version. The VID version could be done quite easily 
using the same HTTP API.

doc: source code service: not like docbase. it's more for control 
of what versions a user can download, discerning between stable, 
unstable versions. also delivers a clean upgrade procedure that is 
easy for the user. one can download scripts, packages of scripts 
and on-demand encapped executables. it works all inside REBOL/Services, 
but I need a "virgin" entry, so new users can get their programs 
through a webbrowser as well.

once they start the program, they can connect to the source server 
to get updates via REBOL/Services. Delivery by the developer to the 
source server is meant to be just as simple.

Sounds like DevBase.

it's nothing like devbase.(sorry, I said docbase)  it's user centric, 
not developer centric.

in fact I hope I'll be able to use devbase with this.

I will explain more when it's ready.

(which I expect will be a year from now at this pace)

Perhaps they will converge. I have big plans for DevBase.

looking forward to that :-)

but the basic idea is that developers should have an easy way to 
distribute their programs and users should have an easy way to upgrade 
their rebol applications. there are some tricks involved to lock 
it down so only specific users can get specific updates for specific 
programs. it may be tied into a purchasing system as well. that's 
where the on-demand encapping comes in.

it is much more than just providing links to scripts on a webpage.

but it has to start at that, so I want to use cheyenne for that :-)

I just changed the secirity model of DevBase to be more fine-grained. 
It would probably be extensible to cover something like that.

secirity -> security

I wonder now if cheyenne can use REBOL/Services' account system for 
login.

A Cheyenne front end could be very useful. Cheyenne could easily 
use REBOL/Services for login.

Part of the plans for DevBase is to clean the code structure to make 
it more modular, to make different front ends easier.

sounds interesting

Doc, you may want to say system/options/quiet: true


I found this in /var/log/system.log on my Mac, when starting Cheyenne 
using Launchd:

Jan  1 11:01:43 Macintosh com.rebol.cheyenne[60072]: /
Jan  1 11:01:43: --- last message repeated 1 time ---
Jan  1 11:01:43 Macintosh com.rebol.cheyenne[60072]: -
Jan  1 11:01:43: --- last message repeated 1 time ---
Jan  1 11:01:43 Macintosh com.rebol.cheyenne[60072]: \

Jan  1 11:01:44: --- last message repeated 1 time ---
Jan  1 11:01:44 Macintosh com.rebol.cheyenne[60072]: |
Jan  1 11:01:44: --- last message repeated 1 time ---
Jan  1 11:01:44 Macintosh com.rebol.cheyenne[60072]: /
Jan  1 11:01:44: --- last message repeated 1 time ---
Jan  1 11:01:44 Macintosh com.rebol.cheyenne[60072]: -

Jan  1 11:01:44: --- last message repeated 1 time ---
Jan  1 11:01:44 Macintosh com.rebol.cheyenne[60072]: \
Jan  1 11:01:44: --- last message repeated 1 time ---
Jan  1 11:01:44 Macintosh com.rebol.cheyenne[60072]: |
Jan  1 11:01:44: --- last message repeated 1 time ---
Jan  1 11:01:44 Macintosh com.rebol.cheyenne[60072]: /
Jan  1 11:01:44: --- last message repeated 1 time ---

Jan  1 11:01:44 Macintosh com.rebol.cheyenne[60072]: -

Jan  1 11:01:44: --- last message repeated 1 time ---
Jan  1 11:01:44 Macintosh com.rebol.cheyenne[60072]: |

Jan  1 11:01:44: --- last message repeated 1 time ---
Jan  1 11:01:44 Macintosh com.rebol.cheyenne[60072]: /
Jan  1 11:01:45: --- last message repeated 1 time ---
Jan  1 11:01:45 Macintosh com.rebol.cheyenne[60072]: -

Jan  1 11:01:45: --- last message repeated 1 time ---
Jan  1 11:01:45 Macintosh com.rebol.cheyenne[60072]: \
Jan  1 11:01:45: --- last message repeated 1 time ---

Jan  1 11:01:45 Macintosh com.rebol.cheyenne[60072]: |

Jan  1 11:01:45: --- last message repeated 1 time ---
Jan  1 11:01:45 Macintosh com.rebol.cheyenne[60072]: /

:-)

Apparently it's not in the main cheyenne.r file, but during a call 
to a sub system (don't know which yet) that causes this.

I think I found the problem in Uniserve:

In uni-engine.r, replacing:

call join form to-local-file system/options/boot [" -s " cmd]

with:

call join form to-local-file system/options/boot [" -sq " cmd]

quiets it down

Thanks for the fix, it will be part of the next release.

great :-)

Doc, are you considering simple HTML templates for .rsp pages, or 
is that already possible?

Such as converting a block of values to a table:

<% print html-table read %. %>

It's not on my Todo list, I plan to make a higher level framework 
for building web applications, where I don't want to mess anymore 
with HTML or Javascript. Kind of VID dialect that compiles to HTML+CSS+JS.

cool

Just like RoR, RSP can use the following <%= %> instead of <% print 
... %>

Kind of VID dialect that compiles to HTML+CSS+JS.
 Now, that's what I'm talking about!!!

Doc - that would be too wonderful, us HTML challenged programmer 
types would be so very happy with such an option!

hi to Gregg -- thx for the invitation to your world...

oops, probably the wrong place ... plz. excuse the noob

http://www.softinnov.org/is not working?

not here either.