For Programmers: Free Programming Magazines  


Home > Archive > PERL POE > August 2005 > namespace request - PoCo::Server::MDP









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author namespace request - PoCo::Server::MDP
Jeff Lowrey

2005-08-26, 7:04 pm

I'm in what I hope is final testing before releasing a public beta of
a set of modules that act as POE components to provide Message Driven
Perl services - in the vein of a JMS provider.

The intent is that someone will be able to do something similar to
#########################
use POE;
use POE::Component::Server::MDP::POEQueuePro
vider;

my $queue = POE::Queue::Array->new();

POE::Component::Server::MDP::POEQueuePro
vider->new(
'inline_states' => {
'on_message' => \&onMessage
},
'Queue' => $queue
);

POE::Kernel->run();

#someone puts stuff on $queue, and following is called for each message.

sub onMessage {
my $msg = $_[ARG0];
print $msg->{'Priority'},$msg->{'ID'},$msg->{'Payload'};
}
#########################

Any objections to the namespace? Better suggestions?
"Perl Messaging Service" has already been rejected... ;-)

-Jeff Lowrey

Rocco Caputo

2005-08-27, 7:02 pm

On Aug 26, 2005, at 16:27, Jeff Lowrey wrote:

> I'm in what I hope is final testing before releasing a public beta
> of a set of modules that act as POE components to provide Message
> Driven Perl services - in the vein of a JMS provider.
>
> The intent is that someone will be able to do something similar to
> #########################
> use POE;
> use POE::Component::Server::MDP::POEQueuePro
vider;


Wow, that's long, and Provider seems to overlap with Server.
POE::Component::MDP::QueueProvider still has some length to it, but
it sounds a lot less redundant. I assume there will be a lot of
modules below POE::Component::MDP.

> Any objections to the namespace? Better suggestions?
> "Perl Messaging Service" has already been rejected... ;-)


Perl Queuing Runtime Server Thingy? :)

--
Rocco Caputo - rcaputo@pobox.com


Erick Calder

2005-08-27, 7:02 pm

> On Aug 26, 2005, at 16:27, Jeff Lowrey wrote:[color=darkred]
>

is a server really a component? wouldn't POE::Server::MDP make more sense?


Matt S Trout

2005-08-27, 7:02 pm

On Sat, Aug 27, 2005 at 05:16:06PM -0400, Rocco Caputo wrote:
> On Aug 26, 2005, at 16:27, Jeff Lowrey wrote:
>
>
> Wow, that's long, and Provider seems to overlap with Server.
> POE::Component::MDP::QueueProvider still has some length to it, but
> it sounds a lot less redundant. I assume there will be a lot of
> modules below POE::Component::MDP.


POE::Server::MessageBus
POE::Component::MessageBus::Client

?

--
Matt S Trout Specialists in perl consulting, web development, and
Technical Director UNIX/Linux systems architecture and automation. Mail
Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information

+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +
Rocco Caputo

2005-08-27, 7:02 pm

On Aug 27, 2005, at 17:26, Erick Calder wrote:

>
> is a server really a component? wouldn't POE::Server::MDP make
> more sense?


As far as I know, applications don't need namespaces at all. If this
is the case, why bother giving it a name at all?

This gives me the opportunity to briefly discuss POE::Stage again.
Source is browsable at http://thirdlobe.com/projects/poe-stage/
browser/trunk/ . It's a prototype base class for the next generation
of POE component, solving a number of current problems that
POE::Component has.

1. Long name. POE::Stage is shorter to type and easier to say, even
if it's not nearly as descriptive. Suggestions welcome.

2. Inconsistent call signature. Event handlers receive two
parameters: my ($self, $args) = @_;. $args is a hash reference with
named parameters. You don't need to memorize the contents of ARG3 as
it varies for each component's response.

3. Fiddling with $_[HEAP] to match response data with request
contexts. POE::Stage uses powerful magic to make sure parts of $self
are always relevant for the current request and/or response context
an object currently is in.

4. Session-scoped resources. Thing of the past. POE::Stage's class-
based event watchers are object-scoped, which is way easier to
comprehend.

5. Others? I forget. It's been a while since I've poked at the
project. If you have some time and inspiration, grab yourself a copy
from the repository: svn co https://thirdlobe.com/svn/poe-stage/trunk .

--
Rocco Caputo - rcaputo@pobox.com


Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com