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 handle
        • At the end of the day, Pipeline isn't about XML, SAX, or anything else. Its about genericity (I hate that word, if it even is a word). I don't really care that much about XML but, and this is the killer, I understand that other people do, and even more to the point:

          I don't care what the data flowing through the pipeline looks like

          I could be YAML if you want.

          The reason why Pipeline was written was as a direct result of loads of people coming up with loads of different implementations of the same thing
        • You wouldn't need to change anything. I probably don't have all the information I'd need to produce a complete answer (I'm also badly hungover) but from what you describe it would seem to me that all you'd need to create is either a new type of SAX::Machine, or something along the lines of AxKit{B2B,NG}.

          However, I think that that would only be useful if your data were XML-like, ie inherently extensible because you need it to be. Otherwise I'd probably fail to see the point of using XML.

          --

          -- Robin Berjon [berjon.com]

        • I don't want to think in terms of receiving one event and emitting multiple events for later on down the line. I want to think in terms of a transaction object ...

          This is the impedence mismatch in a nutshell.

          SAX is simply a pipelineable event processor. The events are quite low level (start/end tags, blobs of text). If you want to have a pipeline that passes generic objects back and forth, then you probably don't want SAX per se -- the overhead of serialization between two SAX handlers is likely ov

          • I'm not sure why you're trying to coax your solution into a SAX pipeline if the data is fundementally incompatible with the SAX event model, or why that's a problem with SAX.

            Mostly 'cos I made the mistake of believing the hype. And over reacted when I realised that the hype wasn't true.