in reply to Show me the missing Big Deal of POE.

Libero is a finite machine meta-language. It includes a tidy state machine description language and a very nice engine for generating real source code from it. It comes with schemas to make machines in C, REXX, x86, several other languages, and even Perl. I like it a lot.

POE is very much a library: code is built with it rather than in it. It also lives at a lower conceptual level: it's abstract state machines rather than any particular kind. This is both a blessing and a curse.

Implementation differences abound: Libero's machines are intended to encompass entire programs; POE's are components that work together by passing message events. Libero's machines are sequential, while POE's are concurrent. Libero's states don't accept parameters; POE's do. Libero doesn't generate a transition/event queue, and POE has one. The list goes on and on.

That said, I still like Libero and it's not at all incompatible with POE. If anything, POE's currently not finite machine enough for Libero, so I'm working on a POE::DFA (deterministic finite automaton) that will make it easier to finish a schema I've been tinkering with. After that I expect to be able to churn out state machines like crazy, which is why I went looking for something like Libero in the first place.

Oh, if anything, POE probably is more like iMatix's SMT (Simple Multi-Threading kernel), which is an add-on for Libero and also part of Xitami. I must admit that I haven't given SMT a really close look, so I may be totally wrong.

-- Rocco Caputo / troc@netrus.net / :)

  • Comment on Re: Show me the missing Big Deal of POE.

Replies are listed 'Best First'.
Re^2: Show me the missing Big Deal of POE.
by Velaki (Chaplain) on Aug 02, 2004 at 10:18 UTC

    In a current endeavor, I am starting to use POE. Admittedly, it's because I don't feel like writing a state machine plus a server; however, it appears that POE seems to make this a bit easier by providing a framework. Of course, it feels a bit like wrapping oneself around MPW, Metrowerks, RogueWave, or MFC, but still it's a decent framework.

    I am curious as to the performance of the beastie in a production environment, as opposed to writing a simpler graph used as a callback table, triggered on transitions, vis-a-vis NerveCenter et al.

    I do believe that writing drop-in components will become easier once I write a more generic Component loader -- or at least settle on a well-defined directory/folder structure for the packages --, since to achieve such ease of extensibility, the Component/Filter/Wheel paradigm must evolve to a new abstraction, such as a generic plug-in with a set directory OR package structure. Just as we tend to write -- or some variant thereof -- ... 

    pacakge Foo;

sub new {
  my $this = shift;
  my $class = ref($this) || $this;
  my $self = {};
  bless $self, $class;
  return $self;
}

1;

    [download]
    ...so too will we see the likes in POE.

    -v
    "Perl. There is no substitute."
[reply]
[d/l]
      I do believe POE makes implementation of event based programs more easier than some of the other frameworks that your mentioned that I have used e.g. MFC. As of right now it might lack some functonality of the big boys but I feel its getting there. As for writing a state engine from scratch, perl says dont re-invent the wheel. If its out there just plug it in. I too am trying some intresting things with POE. Will keep you updated on how it goes.
[reply]

In Section Seekers of Perl Wisdom