Question: MacOS X Bundled Apache Server or Embeded Web Server?

Pierre Sahores psahores at easynet.fr
Sat Aug 26 06:36:01 EDT 2006


Hello Katir,

In theory such a process will block your framework for 10 seconds as  
you expect. In practice, there is, for sure, a way we can design the  
entiere "n-tier" process your are thinking about to have the blocking  
part of it on the client-side part of the solution (AJAX  
xmlhttprequest object calls if the client app is a webbrowser, Rev  
scripting if the client-side app is a Rev one), so you will never  
need to slow-up and breake your server-side queue of tasks. In this  
case, the fact that Rev is not multi-threaded will never be a problem  
because, even if some ones can doubt of this, J2SE deamon are running  
up to teen time slower than Rev deamons (Linux and OSX) :

J2SE supports 3 threads max at once while Rev is queuing each task =  
3 * 10 times unit for J2SE and, only, 3 * 1 times under a Rev server- 
side deamon to have the same quantity (and quality !) of queries  
served to the clients. As you can expect, even if Rev is not multi- 
threaded, the work will be well done by Rev because its ablity to  
speed-up the responses to the queue of requests...

If you give me some more details about the process, you are thinking  
about, i'm sure we will be able to design the solution without having  
to manage synchronious blockings on the server-side.

Kind Regards,

Pierre

Le 26 août 06 à 05:43, Sivakatirswami a écrit :

> Pierre:
>
> If a single engine is running as a daemon, and, as we know,  
> Revolution is no multi-threaded and cannot fork a new  process.  
> What happens if one of your CGI has a "wait 10 seconds" in it... or  
> a blocking call ?  Doesn't this bring down the entire framework for  
> 10 seconds and all other attempts to use the engine are blocked for  
> 10 seconds?
>
> Sivakatirswami
>
>
> Pierre Sahores wrote:
>> Hi Andre,
>>
>> I'm bundeling MC/Rev client-server's applications to Apache since  
>> 1997 in using this kind of architecture. The client part of the  
>> process can be un standard web browser under the Win32, MacOS9/X  
>> or Linux platforms, a webbrowser+AJAX add-ones (XMLHTTPRequest  
>> objects) on the same platforms or MC/Rev client-side apps. All  
>> works very securely in real solutions solded to my customers  
>> (Education, Universities, Humans Ressources Management and Coaching).
>>
>> Perhaps could you have an eye on the basic tutorial i maintain on  
>> the subject at <http://istream.homeunix.com/insead/index_en.html>.
>>
>> Dont hesite to ask me more about the details ;-)
>>
>> Best Regards,
>>
>> Pierre
>>
>>
>> Le 24 août 06 à 01:49, Andre Garzia a écrit :
>>
>>> Hi Folks,
>>>
>>> I am building my soon to be released web application development  
>>> thingy. I am bundling all my libraries (and some third party with  
>>> credits), docs and example.
>>>
>>> But since I talked with Dan and others during RevConWest, I  
>>> decided that the most important part of this package is the out- 
>>> of-the-box experience. The hardest thing about CGI and WebApps  
>>> for rev users is usually setting up the environment. The idea is  
>>> to develop locally and then deploy when ready. I can't really  
>>> build this for Windows, I expect help on that later. So the idea  
>>> is that there's a home stack that sets everything up.
>>>
>>> Till today I was bundling the LiteSpeed Web Server <http:// 
>>> www.litespeedtech.com> server with the package. The server would  
>>> be all set up out of the box so that you could just launch and  
>>> play. The problem is, the thing is not running CGIs, the plain  
>>> old ones... they run once, then the server deadlocks. ARGH!!!! I  
>>> thought about using cherokee web server <http://www.0x50.org/>  
>>> but then, it comes out in source form and when it compiles it  
>>> hard code some paths for the dynamic loading libraries, so you  
>>> cannot really build it and then just bundle. You must compile it  
>>> for each installation. Thats the same trouble with Lighttp  
>>> <http://www.lighttpd.net/>, and building it with static options  
>>> makes a huge server like 158mb and still it hard code the paths.
>>>
>>> The MacOS X Apache server is not ready for FastCGI, for that we  
>>> need to install the modules, which is easy. Actually thats not  
>>> hard, simple commands and a revolution made stack could drive  
>>> that installation easy. But again MacOS X out-of-the-box lacks  
>>> the needed C compiler for that, only those that installed XCode  
>>> development tools have the needed stuff to build Apache Modules.
>>>
>>> So here I am. The little servers all have some trouble or  
>>> another, the MacOS X bundled one is fine, but again, you need to  
>>> download 1GB XCode tools just to build simple couple megs apache  
>>> module...
>>>
>>> any clue out there folks? is there any autoconf magician here  
>>> that can build a lighttp install with relative paths instead of  
>>> absolute ones (I tried and it didn't like).
>>>
>>> Can we use otool to rewrite the linkers absolute path using a  
>>> relative one like we do for frameworks (using @executable_path).
>>>
>>> Argh, I am looking for help.
>>>
>>> Andre
>>> _______________________________________________
>>> use-revolution mailing list
>>> use-revolution at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your  
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>>
>>
>> -- 
>> Pierre Sahores
>> www.sahores-conseil.com
>>
>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>

--
Pierre Sahores
www.sahores-conseil.com





More information about the use-livecode mailing list