[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] AppleEvents, hard to grasp!



At 10.41 +0100 1999.11.15, Axel Rose wrote:
>>At 23.39 +0100 1999.11.14, Axel Rose wrote:
>> >I try to write a CGI. I need AppleEvents. I tested Mac::Glue.
>> >This works but is too slow for my target application.
>>
>>I still think that you are better off writing your own "server" in Perl on
>>some alternate port so you don't need to worry about startup times.  Why is
>>this solution insufficient?
>
>If I setup my own http server process in MacPerl I have to
>a) connect my main service (http on port 80, accessible from everywhere,
>WebStar with realms, etc.) with the MacPerl service on a different port
>on the same machine

What do you mean, "connect with"?

>b) have all request serviced by the MacPerl process

Not at all.  I explained this before: the MacPerl process would only handle
requests that you would normally send to the CGI.


>a) I simply don't know how, especially how to handle the different port
>when accessing the whole system from outside through a firewall

Open up one additional port on the firewall.  It should be that simple.


>> >IMHO only a dozen or so people are able to work efficently
>> >with MacPerl/CGI and AppleEvents driven databases.
>>
>>Well, I don't think anyone is able to work efficiently with MacPerl CGIs,
>>of any kind.  MacPerl CGIs just aren't very good for anything serious.
>
>It's sad to hear that from you.
>My hope though is that the next MacPerl release makes CGIs easier to use
>(threads).

Well, I think CGI is ineffecient for most serious projects on ANY platform.
Let's take a DBI CGI.  You have to load in all that XS code, then connect
to the database, then do your query, then close the connection.  That's not
much different from the problems with using something like Mac::Glue with
CGI: you have a lot of overhead.  MacPerl compounds the problem by only
allowing you to run one Perl program at a time, but still ... the necessary
solution is some persistent process that is always running, or is always
compiled and ready to run.  And you can do that now by converting CGIs to
mini-HTTP servers.  It completely eliminates the problem, while introducing
mostly small, surmountable, problems.

-- 
Chris Nandor          mailto:pudge@pobox.com         http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10  1FF77F13 8180B6B6'])

# ===== Want to unsubscribe from this list?
# ===== Send mail with body "unsubscribe" to macperl-request@macperl.org