Rebol/Apache?

I have no info like that. MS based webserver is a piggy business, sorry. There is still tens of percent of Apache marketshare. Or you suggest me, that as a hobbyist or mid-business, I should set-up Win based machine, where I have to pay for each bit of functionality? How much does server Win2K cost? How much is MSSQL for? I have one red-hat server installed, and also have serveral friends running both Unix and Win based servers. The beauty of Unix based solutions is - you don't generally need to boot your server for many many months :-) I mentioned Rebol/Apache because it was concrete product - it was already done. So I thought it would requeire just some kind of recompile or not so much of a work .... I know author of Apache doesn't work with Apache dev. team, but I have currently no info indicating /Apache is gonna be discarded/non-further-developed. Hmm - even IBM offers now Linux based servers, even Linux based mainframes .... I am not sure of Apache dead-end ... Cheers, -pekr-

Ah, so ... it should be something magnificant then ;-)

Thanks, I like your explanations so much :-) I should store them and start providing jeff's vocabulary :-) -pekr-

Is this DocKimbel's solution? Or RT's one? After I saw price of 49 USD per all platforms, I bought my Key in one minute! It was really a good step. I also pay for rebol.cz domain, although it still waits for new team to crystalize .... I would like to offer FastCGI (or Apache) option. FastCGI is something I mentioned two or more years ago here. The problem is - I can't affort (=am not willing to pay) some uhm 400 USD for /Command, as the price is reaching nearly average salary in some of regions of Czech Republic. What is even more - there is no multiplatform price transparency yet. So - what is /Command FastCGI solution about? Internal solution? External library? Thanks, -pekr-

Our own. We looked into it first in the context of REBOL/Express and expect to have FastCGI support ready for Command 2.0.

Basically Command FastCGI allows you to keep a Command-based server running as a process. Incoming http requests are forwarded by the web server through TCP. The protocol running across the TCP channel is called FastCGI. The implementation is done within Command. On the web server you need a FastCGI plug-in/module (freely available for Apache, available commercially for other servers). -- Holger Kruse [holger--rebol--com]

Our own. We looked into it first in the context of REBOL/Express and expect to have FastCGI support ready for Command 2.0.

Basically Command FastCGI allows you to keep a Command-based server running as a process. Incoming http requests are forwarded by the web server through TCP. The protocol running across the TCP channel is called FastCGI. The implementation is done within Command. On the web server you need a FastCGI plug-in/module (freely available for Apache, available commercially for other servers). -- Holger Kruse [holger--rebol--com] -- To unsubscribe from this list, please send an email to [rebol-request--rebol--com] with "unsubscribe" in the subject, without the quotes. please reply to: [david--vydra--net]

Yes.

You would have to put a proxy between your web server and the Command instances which acts as a dynamic scheduler. -- Holger Kruse [holger--rebol--com]

We don't know yet, sorry. MacOSX is fairly high on our list of priorities though. -- Holger Kruse [holger--rebol--com]

making blocking calls to the db?

FastCGI?

instances

-could such proxy be built in Rebol? Would it be efficient? Sterling's proxy.r is nice example of proxy built directly in rebol. It registers pairs of "request" "answer" ports and does some kind of scheduling (based upon events occuring on certain ports we are waiting on). Maybe one /command process could act as proxy and FastCGI interface, and it could 'launch another rebol instances to do the task, or few rebol instances could be pre-launched and wait for instructions on some TCP port. IIRC there were script called "bounce" or something similar on rebol.org, showing task distribution thru several interconnected rebols ... ... or am I completly wrong? Thanks, -pekr-

/Apache has not been "abandoned", its concepts and goals have rather been integrated into the regular Command 2.0 release. In the original plans /Apache used to be a version of /Command (with similar intended pricing as /Command, but distributed and sold separately) which would be provided in mod_rebol.so format instead of as a stand-alone application. This concept has been superceded by FastCGI support in Command 2.0. FastCGI support is superior to the /Apache module-based solution in many ways: - It works with other web browsers than just Apache. - In one mode of operation it is fully compatible with CGI, i.e. no changes to scripts or calling conventions are needed. Only the Apache config has to be changed. - In another mode it allows the parallel, multiplexed execution of multiple requests within a single REBOL process, through fastcgi:// ports. - It works across networks, i.e. the REBOL FastCGI processes do not have to run on the same box as Apache. - It is compatible with TCP-proxy-based load balancing environments. - Even in multiplexed mode the changes to existing CGI scripts are minimal. - Performance actually tends to be better than with a module-based approach, because of better parallelization, separation, buffering and piping of requests through TCP. See www.fastcgi.com for more information on this. /Apache could not support any of these things. The only advantage of /Apache over FastCGI is that /Apache provides a more direct link to the Apache server, allowing you to do some unusual things in Apache's request pipeline. Those features are rarely used though. The bottom line is that Command 2.0 with FastCGI provides more functionality, better performance and, being part of the Command and Command/View bundle, at an overall lower price than was intended with /Apache. -- Holger Kruse [holger--rebol--com]

functionality, better

overall

Ah so - I thought Apache was supposed to be ... should I dare to mention the word? - "free" :-)) Well, OK, as for commercial application, I will probably buy /Command for my corporation usage, but as a hobbyist, which would like to support some rebol server scripting the price is too high. But maybe some of list members will come with MySQL + PostGressSQL + FastCGI library wrapper and provide it a) for free b) for some little fee ... One specific question ot /View component being present in /Command. Today I saw some (probably PHP based, but not sure) analyse of web accesses graphs, and it seemed to me that it was generated dynamically, including fonts. So - is the situation with View regarding fonts usage the same? Is absence of X libraries really so often case? I somehow see View compositing limited, once we can't use texts in images ... Thanks, -pekr-

True, but there is no good way around this. The problem is not just lack of X libraries. In order to render text you would also need access to an X server, i.e. a workstation with an X server running, configured to allow X access from the web server. -- Holger Kruse [holger--rebol--com]

Am 22.05.01, 21:35:48, schrieb Holger Kruse <[holger--rebol--com]> zum Thema [REBOL] Re: Apache:

[SNIP] Apache web browser? <g> -- Binary/unsupported file stripped by Listar -- -- Type: application/x-pkcs7-signature -- File: smime.p7s -- Desc: S/MIME Cryptographic Signature

web servers :-) -- Holger Kruse [holger--rebol--com]

PHP actually has access to some font rendering engines. I don't recall the details, but one of my friends wrote some code to generate text from PHP: http://www.ing.univaq.it/php3utils/left_item.php3?Your_text_string+3 We are using it to generate the menu on the left: http://www.ing.univaq.it/ The server is a Sun workstation with Solaris; it HAS X running, but I'm quite sure it would work without it too. Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

PHP relies on the gd library for those functions. gd library in turn relies on the following: libm.so.6 => /lib/libm.so.6 (0x4004d000) libpng.so.2 => /usr/lib/libpng.so.2 (0x4006e000) libz.so.1 => /lib/libz.so.1 (0x40094000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x400a3000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x400c5000) libttf.so.2 => /usr/lib/libttf.so.2 (0x40102000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x4012e000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4013e000) libc.so.6 => /lib/libc.so.6 (0x4022a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000) So it does in fact require a minimal X installation. Deryk -- Binary/unsupported file stripped by Listar -- -- Type: application/x-pkcs7-signature -- File: smime.p7s -- Desc: S/MIME Cryptographic Signature

Minimal X installation is not enough. You would need a running X server to connect to. Font rendering is done by the server, not by the X libraries. The only viable alternative is to use a completely different font engine, but then there is the cross-platform issue, plus rendered text would look different than in X. Perhaps in a future version... -- Holger Kruse [holger--rebol--com]

Am 25.05.01, 17:05:16, schrieb Holger Kruse <[holger--rebol--com]> zum Thema [REBOL] Re: Apache:

all

server to

libraries.

making renderer based on fonts? Oberon mixes own bitmaps and system-whatever well (well, the system-whatever may look better :) so one could test in view with a self-rendered default-font? After all its for images, which don't know the fonts of the viewers engine. Own fonts are more platform eventually, since pics from windows are different to that from X? hm. with /pro, maybe an interface to a users .dll-renderer to write text to bitmaps? just thinking -Volker