Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • After reading the newsletter and browsing the site I still have no idea. The closest I got was that it is a "networking toolkit." One of the haikus in the FAQ mentioned Perl - is that why it's on use.perl.org?

    Sticking with LWP,
    -sam
    • Stem is all pure-Perl, though it does rely on the Event module (which is C).

      It is designed to support asynchronous message-based systems. Does that help?

      Saying that you're sticking with LWP is kind of meaningless. Stem is largely orthogonal to LWP.

      A representative Stem application might be a process that responds to outside requests via a socket, delegates work to multiple child processes (like Apache, perhaps) and then responds to the request.

      The nice thing about using Stem for that is that you would
      • So more like Net::Server than LWP? -sam
        • Yes, but ...

          It can do a _lot_ of stuff for you.

          For example, IPC and RPC between multiple Stem servers is trivial.

          You can also use Stem to do client/server stuff with a Stem client and a Stem server.

          It can also run as a standalone daemon. For example, you could run a Stem daemon that fired off messages at regular intervals to other Stem servers (kind of like cron).

          Basically, if you have to do any sort of network project (client/server, multiple servers, messaging across machines) Stem can be very helpf
          • Oh, dammit - this might ruin my Oyster project! Though, he doesn't have the security set up that I need. Hmmm....

            And, of course, I must ask if those messages are being exchanged in XML format, because *everything* is always better in XML format. :-P

            • improved security is high on our todo list. stem supports ssh but it needs improving. also we plan to support SSL and stunnel. the goal is to allow any style of secure channel for any socket, stem to stem or stem to outside world.

              as for xml (blechh!) formatted messages, that very doable as the messages are just simple data structures. i recently started integrating YAML [yaml.org] into stem and it is used to serialize objects over a socket. we plan to use YAML for config files as well as messages. in fact, plans are for the message format to be pluggable and selectable so you can use different styles at the same time. the message style will be in the plain text header of all messages. so, adding xml message support to that will be trivial.