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.
  • SAX is complicated purely because it deals with XML at a low level, and XML is actually quite complicated. As with XML, the trick lies is using just that portions you need. SAX, because it is so low-level, should be built upon so it does not have to be used directly. Assembling SAX filters to form pipelines and more complicated beasties is quite easy, and there are an ever growing number of filters to make it so you *don't* have to mess with SAX internals directly.
    • I'm not sure that that suffices to make it qualify as complex. In the vast majority of cases (ie >95%) I only need two things from SAX: elements and character data.

      The reason I find SAX simple is because you can simply ignore what you don't care about. It only gets complex when you want to deal with complex XML.

      In that respect, I'd call it more complete than complex. Easy things easy and all that ;)

      --

      -- Robin Berjon [berjon.com]

      • How much would I have to change if I wanted to make things so that each SAX filter was actually run from within a standalone daemon servicing a reliable message queue. It's also a requirement that each daemon should be able to serve as a filter in different filter pipelines.

        I'm not saying that this should be easy to implement, but the Pipeline API that I've been envisaging should at least make things so that I only have to change the transport model and all the other stuff will remain untouched.

        I don't w
        • How much would I have to change if I wanted to make things so that each SAX filter was actually run from within a standalone daemon servicing a reliable message queue. It's also a requirement that each daemon should be able to serve as a filter in different filter pipelines.

          This is what proxies are for.

          To me, it seems like Pipeline is a combination of allowing an alternate method calling convention between pipeline stages (handlers, in SAX terms), and a data store mechanism (the super class of the handler, in SAX terms).

          SAX doesn't have a separate concept of a data store, nor a separate concept of a dispatch mechanism. The data store is an instance of the handler itself, and the dispatch mechanism is method calls on the next handler in the chain. But the beauty of that is it's simple for simple needs, and because this is perl, you can circumvent all that plumbing to do whatever you need to do. You could create your SAX handler with a "store" entry, and only store data there using its methods. And for the method calls you can use a proxy.

          I'm not saying you should use SAX, I'm just suggesting that SAX isn't as complex as you think it is (which is entirely our fault probably), and that it's probably a decent platform on which to build on, or at least investigate further.