Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Rebol/Apache?

 [1/27] from: petr::krenzelok::trz::cz at: 30-Mar-2001 6:11


Hi, if you will look at RT's product website, you will notice there is no mention of Link/World, and they are mentioning Rebol/View and Rebol/View/Pro there instead. However, I would like to enter Apache territory once again. So the question for Jeff and Dan: Jeff - would it be too much of work to rebuild Rebol/Apache, based upon Rebol/Core 2.5? Dan - would you consider /Apache release based upon Core/Pro? The question is, if addition of shell and library interfaces to Apache wouldn't be considered as a break of security. Then maybe both components could be allowed at least during the boot-load time .... Thanks, -pekr-

 [2/27] from: ptretter:norcom2000 at: 29-Mar-2001 22:46


Hi Petr, maybe you should look at the market share of IIS and where its heading. the /Apache thing was being developed just a short time before I learned of REBOL but I have seen many a post about it. I think that if you look at the propositions about all the other products its clear that /Apache is on the backburner and to me I would be surprised if its still in work at all. I really don't think its necessary given the resources and outlook of RT. Correct me if I'm wrong. Paul Tretter

 [3/27] from: petr:krenzelok:trz:cz at: 30-Mar-2001 8:08


Paul Tretter wrote:
> Hi Petr, > maybe you should look at the market share of IIS and where its heading. the
<<quoted lines omitted: 4>>
> really don't think its necessary given the resources and outlook of RT. > Correct me if I'm wrong.
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-

 [4/27] from: jeff:rebol at: 2-Apr-2001 9:11


Howdy, Petr: Sorry for the delay in responding-- been rather busy. No it shouldn't be too much work (maybe a week to update to the latest apache module APIs), but it's not likely any time soon. Bigger fish to fry. (-: ( Translation: "Bigger fish to fry" is a slang phrase that means bigger opportunities to go after for right now. (-: )

 [5/27] from: dev1:awarehouse at: 29-Mar-2001 23:05


Paul, See http://www.netcraft.com/survey/ Why would the stagnant or declining market share of IIS vs. Apache indicate that work on Rebol /Apache would not be worthwhile? I can see that RT may have more immediate priorities, but IIS does not appear to provide any reason to shy away from Apache-related development. Cheers, Dave De Graff

 [6/27] from: petr:krenzelok:trz:cz at: 3-Apr-2001 6:21


[jeff--rebol--net] wrote:
> Howdy, Petr: > > Sorry for the delay in responding-- been rather busy. > > No it shouldn't be too much work (maybe a week to update to > the latest apache module APIs), but it's not likely any time > soon. Bigger fish to fry. (-:
Ah, so ... it should be something magnificant then ;-)
> > ( Translation: "Bigger fish to fry" is a slang phrase > that means bigger opportunities to go after for right > now. (-: )
Thanks, I like your explanations so much :-) I should store them and start providing jeff's vocabulary :-) -pekr-

 [7/27] from: rondon:andrade:uol at: 25-Apr-2001 7:54


Hi ! What about Rebol/Apache ? Does it come with Rebol/Express ? I'm making some tests using cgi, but I'm having problems when I do a server stress as test.. Any tips ? Thanks in advance. Rondon

 [8/27] from: carl:rebol at: 25-Apr-2001 9:18


REBOL/Command 2.0 will have Fast CGI support. That should help a lot with processing speed.... nearly as fast as an Apache mod.

 [9/27] from: petr:krenzelok:trz:cz at: 25-Apr-2001 19:09


----- Original Message ----- From: "Carl Sassenrath" <[carl--rebol--com]> To: <[rebol-list--rebol--com]> Sent: Wednesday, April 25, 2001 6:18 PM Subject: [REBOL] Re: About Rebol/Apache
> REBOL/Command 2.0 will have Fast CGI support. That should help a lot > with processing speed.... nearly as fast as an Apache mod.
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-

 [10/27] from: rondon:andrade:uol at: 25-Apr-2001 14:54


Hi Carl, 1. When do you think Rebol/Command 2.0 will be available ? 2. What About Rebol/Express ? As I have Apache, Don't you think it could be a solution for me ? Thanks in advance. Best Regards!! Rondon.

 [11/27] from: holger:rebol at: 25-Apr-2001 10:48


On Wed, Apr 25, 2001 at 07:09:15PM +0200, Petr Krenzelok wrote:
> Is this DocKimbel's solution? Or RT's one?
Our own. We looked into it first in the context of REBOL/Express and expect to have FastCGI support ready for Command 2.0.
> So - what is /Command FastCGI solution about? Internal solution? External > library?
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]

 [12/27] from: dvydra2:ya:hoo at: 25-Apr-2001 22:44


Holger, If I am trying to build a multiuser site with db support, am I still making blocking calls to the db? If so, is there a way to load-balance several R/Commands running FastCGI? Regards, David Holger Kruse <[holger--rebol--com]> wrote: On Wed, Apr 25, 2001 at 07:09:15PM +0200, Petr Krenzelok wrote:
> Is this DocKimbel's solution? Or RT's one?
Our own. We looked into it first in the context of REBOL/Express and expect to have FastCGI support ready for Command 2.0.
> So - what is /Command FastCGI solution about? Internal solution? External > library?
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]

 [13/27] from: warp:reboot:ch at: 26-Apr-2001 10:48


please tell if macOSX port of command 2.0 will be in 1 month, 3 month, 6 month.. this would really help. thank you and have a nice day Will Arp

 [14/27] from: holger:rebol at: 26-Apr-2001 7:08


On Wed, Apr 25, 2001 at 10:44:06PM -0700, David Vydra wrote:
> Holger, > > If I am trying to build a multiuser site with db support, am I still making blocking calls to the db?
Yes.
> If so, is there a way to load-balance several R/Commands running FastCGI?
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]

 [15/27] from: holger:rebol at: 26-Apr-2001 7:12


On Thu, Apr 26, 2001 at 10:48:55AM +0200, Will Arp wrote:
> please tell if macOSX port of command 2.0 will be in 1 month, 3 month, 6 > month..
We don't know yet, sorry. MacOSX is fairly high on our list of priorities though. -- Holger Kruse [holger--rebol--com]

 [16/27] from: petr:krenzelok:trz:cz at: 26-Apr-2001 18:49


----- Original Message ----- From: "Holger Kruse" <[holger--rebol--com]> To: <[rebol-list--rebol--com]> Sent: Thursday, April 26, 2001 4:08 PM Subject: [REBOL] Re: About Rebol/Apache
> On Wed, Apr 25, 2001 at 10:44:06PM -0700, David Vydra wrote: > > > > Holger, > > > > If I am trying to build a multiuser site with db support, am I still
making blocking calls to the db?
> Yes. > > > If so, is there a way to load-balance several R/Commands running
FastCGI?
> You would have to put a proxy between your web server and the Command
instances
> which acts as a dynamic scheduler.
-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-

 [17/27] from: holger:rebol at: 22-May-2001 10:58


On Tue, May 22, 2001 at 04:02:57PM +0200, Petr Krenzelok wrote:
> So if we are talking tools once again, why to abandon /Apache for e.g.?
/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]

 [18/27] from: petr:krenzelok:trz:cz at: 22-May-2001 21:20


> 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.
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-

 [19/27] from: holger:rebol at: 22-May-2001 13:35


On Tue, May 22, 2001 at 09:20:56PM +0200, Petr Krenzelok wrote:
> 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 ...
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]

 [20/27] from: agem:crosswinds at: 22-May-2001 22:55


Iam a little bit confused. Oberon V4 has comperable download-size and font-engine embedded. Are fonts really that hard?! Volker
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 22.05.01, 21:35:48, schrieb Holger Kruse <[holger--rebol--com]> zum Thema [REBOL] Re: Apache:

 [21/27] from: deryk:iitowns at: 23-May-2001 7:46


Holger Kruse wrote: [SNIP]
> - It works with other web browsers than just 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

 [22/27] from: holger:rebol at: 22-May-2001 16:59


On Wed, May 23, 2001 at 07:46:09AM +0800, Deryk Robosson wrote:
> Holger Kruse wrote: > [SNIP] > > - It works with other web browsers than just Apache. > [SNIP] > > Apache web browser? <g>
web servers :-) -- Holger Kruse [holger--rebol--com]

 [23/27] from: g:santilli:tiscalinet:it at: 25-May-2001 15:06


Holger Kruse wrote:
> 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.
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/

 [24/27] from: deryk:iitowns at: 25-May-2001 22:02


Gabriele Santilli wrote:
> Holger Kruse wrote: > > True, but there is no good way around this. The problem is not just lack of
<<quoted lines omitted: 9>>
> The server is a Sun workstation with Solaris; it HAS X running, > but I'm quite sure it would work without it too.
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

 [25/27] from: petr:krenzelok:trz:cz at: 25-May-2001 17:40


As for me I would still prefer minimal X installation than no text at all ... -pekr-

 [26/27] from: holger:rebol at: 25-May-2001 9:05


On Fri, May 25, 2001 at 05:40:21PM +0200, Petr Krenzelok wrote:
> As for me I would still prefer minimal X installation than no text at all > ...
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]

 [27/27] from: agem:crosswinds at: 25-May-2001 22:37


>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 25.05.01, 17:05:16, schrieb Holger Kruse <[holger--rebol--com]> zum Thema [REBOL] Re: Apache:
> On Fri, May 25, 2001 at 05:40:21PM +0200, Petr Krenzelok wrote: > > As for me I would still prefer minimal X installation than no text at
all
> > ... > 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...
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

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted