Hi Uri,
I think most (all???) of what is needed can be found at:
http://www.cs.wustl.edu/~schmidt/ACE.html
I know it's C++, but this framework is well designed - and it is portable
:-) (in other words: it has been ported to an impressive number of
platforms). The features (read patterns) that can be found in this library
could be integrated into perl, or possibly perl could be built on top of
ACE. Adding support for CORBA would then be a natural extension to perl
since everything else would be in place.
Best regards
Espen Harlinn
Senior Engineer, Software
Seamos AS
---------------------------------
mailto: [EMAIL PROTECTED]
Phone: +47 55 22 07 81
Fax: +47 85 02 29 43
Address:
Stokkedalslia 5
5155 BØNES
NORWAY
---------------------------------
> -----Original Message-----
> From: Uri Guttman [mailto:[EMAIL PROTECTED]]
> Sent: 4. juli 2001 08:09
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: new event loop
>
>
>
> i am going to make a proposal that we ('we' to be defined
> later) develop
> a new common event loop with two major goals in mind:
>
> 1. the event loop should be fully portable over all modern unix OS's
> and the win32 server flavors (nt, 2k).
>
> 2. be a test bed for perl6 language level event API and new
> features.
>
> the first goal is to make it easier to port event loop based
> applications and systems such as POE, perl/tk, perl/gtk and Stem. some
> of these work ok under win32 and others don't. having a single event
> loop we can all use and support would be very good for the perl
> community.
>
> the second goal is meant to help get some parts of perl6 internals
> moving along. we have all agreed that perl6 will have an event loop
> and/or event handling in the op dispatcher. here is a chance
> to work on
> its perl level API (see RFC 350 for my proposed API), add new features
> such as async file I/O (which has working but different
> system API's on
> solaris, BSD* and win32), and learning about the portability issues.
>
> because the API will be new and we will adding new features, i think
> this is best done as a new module and not as a rewrite of
> Event.pm. but
> that module's API had a strong influence on my RFC. also i think the
> best implementation for it would be for most of it to be in perl with
> inline C for the critical code such as signal handling and specialized
> system calls (such as async file i/o). we can benchmark it later and
> move any bottlenecks into inline c as well.
>
> we have a mass of great event level talent around here. also all the
> critical OS platforms are covered. this should not be a very difficult
> project and i think the core of it could be done in a couple of months
> by a smallish and focused team. adding the async file i/o
> stuff will be
> the hardest part and may take some more time.
>
> all the work done to support async file i/o can be transferred to
> perl6. also the API will be tested and fine tuned so we gain that as
> well. the module can't be directly used in perl6 as its event loop
> support has to be more tightly integrated with the op dispatch loop.
>
> so what are your thoughts? we can make up a new list
> ([EMAIL PROTECTED] ?) for this or even take over some defunct
> perl6 list.
>
> uri
>
> --
> Uri Guttman --------- [EMAIL PROTECTED] ----------
http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11
Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
