Re: [MacPerl] Perl Shared Library (was Re: [MacPerl] ports and builds)

[Matthias Neeracher <neeri@iis.ee.ethz.ch>]

In article <1295704802-112601882@xplain.com>, Jeff Clites <online@mactech.com> writes:
> My main point, though, which probably got lost in my wordiness, is that as
> the author of a standalone, you would have more control/flexibility as to how
> your app behaves.

That's a good point. As soon as you have severl faceful Perl based
applications, executing them with a single multithreaded server is not going to
do much good.

> For CGI, you could run multiple CGI simultaneously, and they could call
> one another.

This, I think, would still work better in a single, multithreaded faceless
server.

> Secondly, though, even with the same creator codes, you can target
> AppleEvents based on ProcessID, and you can use name and FSSpec in addition
> to creator code to help you decide which process to target with an AE. This
> is cleaner and more in line with the normal way of doing things than sending
> all of your events to the "main" MacPerl app with additional info about which
> script to run. This lets you thing of your scripts as apps rather then
> scripts. 

Yes, as soon as a script takes more AppleEvents than just its creation event,
executing it in its own application makes sense.

>> But, if it came down to a choice, I would rather see threading in the
>> MacPerl app than a shared library.

> I didn't mean for them to be mutually exclusive. Threading is probably more
> important, but also probably more work.

This discussion is convincing me increasingly that a shared, multithreading
library is the way to go.

Matthias

-- 
Matthias Neeracher   <neeri@iis.ee.ethz.ch>   http://www.iis.ee.ethz.ch/~neeri
   "I'm set free to find a new illusion" -- Velvet Underground

***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch