World: r3wp

Conf file is ok too, using the 'listen keyword. You should not change 
it directly in the source code (the HTTPd.r port-id value is override 
by the following line in %cheyenne.r : foreach p any [port-id [80]][control/start/only 
'HTTPd p]

aha .. btw - how do I get to admin portal?

How close do you think you are to 1.0 relese candidates?

I would not prolong it for much longer :-) If ppl see alpha, they 
might be scared. If you feel it is solid enough already, I would 
go for 1.0.

btw - any chance of AddHandler like directive?

AddHandler: it's on my Todo list for 1.0 :-)

I'd really like to have the admin control panel in 1.0. So maybe 
I'll delay until I'll add, at least minimal, control panel.

In the meantime, I have also on my todo list a dedicated web site 
for Cheyenne. I'll work on that in the next days.

Doc, I've had talks with Carl about this, and i think he's more relaxed 
about it.  But you're probably right, so just leave it enfaced.

About Service.dll .. is this just for Cheyenne, or is there a general 
way for all Rebol apps to run as a service?

As a remainder, all the Cheyenne source code, including the service.dll 
source is release under BSD license.

=> "as a reminder ... "

Thanks for the fix :-)

Re service.dll : it could be used to add NT-Service support for any 
REBOL app. But currently, there's a few hardcoded parameters in the 
C source, so it would need at least a recompilation to work for another 
app. I was thinking about packaging this into a simple library...I'll 
see if can find some time to do that. But, in all cases, it requires 
at least /Library component.

that sounds great.

If it is solid, I could use such a dll right away.

It's in the latest Cheyenne distro.

Have you looked into srvany, seen how it interacts with the process 
it is loading?

not me .. I normally use fire daemon to run rebol scripts as services.

Maybe we could have service support in R3 as well?

There will be. It is planned.

I'm a little curious as to what service.dll does. As Dockimbel said, 
it is currently Cheyenne-specific, and it currently doesn't come 
with source (that I can find yet), but looking at the calling source 
it seems that it does not handle all of the service-related functions, 
just "ServiceLaunch". I wonder if there would be some merit to putting 
wrappers for the other service functions in that dll, or converting 
the ServiceLaunch function to REBOL and just doing calls to system 
standard dlls. Pulling the existing REBOL wrapper functions out into 
a seperate script and generalizing them would probably be a good 
idea, at the least.

See Cheyenne/service for the C source

The 0.9.17 beta source that I had doesn't have that directory, but 
upon redownloading the file it does. Thanks tor the heads up.

Yes, he said that he re-released that archive with the source.

service.dll does has a minimal effort to support services. It has 
only starting and stopping support. Stopping triggers a UDP packet 
sent to Cheyenne process to notify the shutdown message. That's the 
only way to communicate with a REBOL process. Windows message cannot 
pass because it requires a permanent window structure (not possible 
in service mode). Pipes coud be a solution but they don't trigger 
events in REBOL wait loop.

To be more accurate, it's possible for a service to have an opened 
window  (even if it's not visible) to receive messages, but in this 
case, I never was able to make it survive a session logoff / logon 
sequence. In Windows, there's also threads message queues, but REBOL 
doesn't seem to trigger events from that channel too. If SYSTEM port 
was able to support that way to communicate, that would be a better 
way for the DLL to transmit messages from the service manager.

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)