Sterling,
concerning the "todo" part:
- as Tim Crook wrote, Sablotron is certainly meant to be thread-safe now
(actually since 0.42). If it's not, it's a bug. I should say we did
receive, a report of a crash apparently happening only in a
multi-threaded setting (from Sven Neumann), but since we were unable to
reproduce it, we couldn't find the cause although we tried hard.
- the point concerning error reporting appears to be a bug too. When a
processing error occurs, all processing (or parsing) should stop and the
error should be reported at once.
In both cases, test files (or code) exhibiting incorrect behaviour would
be most appreciated. Please include relevant information (version,
platform etc.)
Tom Kaiser
Sterling Hughes wrote:
>
> Hey,
> Sorry to here that (for two reasons)...
>
> >From what I knew/understood from some messages on the mailing list you didn't
> want to commit your module to our CVS server. And myself, being one who hates
> politics and loves coding, decided to take their word for it and go implement it
> myself (I also disagreed on some points of implementation, but I could have
> discussed that with you and made the changes to your code).
>
> It actually took me quite a while (27 hours of programming + debugging, and
> another 9 for stuff like installing Sablotron and learning the API) to make this
> module, its sucks that I had to re-write it.
>
> Actually a quick look at the cvsusers file shows that you've had commit access
> for quite some time now (about a month, maybe more), so (unbeknownst to you I
> guess) you've had the ability to commit this extension for a while now.
>
> The new module was written from scratch, comparing implementations it has a
> couple improvements both API wise and internal design wise:
>
> Internal improvements
> - One function to store both log and error messages. Instead of two
> identical functions.
> - Log + Error messages are not copied into an identical array and then
> parsed on the fly when a request for the messages is made, instead they
> are
> parsed when the error is caught, with less memory required, and placed
> into
> a linked list of errors, which is cleared after every error.
> - The module implements PHP's threadsafe features, not really important
> yet,
> since Sablotron is not threadsafe. However, when Sablotron becomes
> threadsafe, the PHP module will be ready.
> - The module uses the latest Zend API macros and functions,
> adding increased speed, error checking and making it less susceptible to
> changes in the Zend API.
> - The module uses the 0.43 API functions such as SablotProcessStrings
> and
> SablotProcessStringsWithBase
> - The code looks nicer (is more readable), of course this is a
> completely
> biased opinion, however, it is better documented and conforms to K&R
> style guidelines.
> - The code is consistent with the other code in PHP. ie, it looks like
> all the
> other committed code.
>
> API Improvements....
> - Output buffering support, meaning you can go:
> <?php
> xslt_output_begintransform("some.xsl");
> // All output is put through some.xsl
> xslt_output_endtransform();
> ?>
> - Full support for the SAX Handlers
> - Optional support for the error handlers, see wish list support for the
> reasons for this.
> - Support for a simple API which does simple transformation analagous to
> the SablotProcessFiles, SablotProcessStrings and SablotProcess
> functions,
> different but same functionality.
> - Not an improvement, but also contains a more advanced API that uses a
> Sablotron Processor.
>
> Things I wish Sablotron had (I know you're all very busy and you probably
> already have these things on your todo list):
>
> - Support for multiple instances of the Sablotron processor. Bad things
> happen
> when two concurrent processes access Sablotron at the same time.
> - Error handling so that the error messages are actually sent to the error
> mechanism before the rest of the document is parsed. Currently they are
> only
> sent when the processor is destroyed (from what I understand). The reason I
> made the extra error handling optional is that I found unless you exited out
> of
> the program with PHP on error, later functions would cause a Segmentation
> fault (by Sablotron). Even when I exited out of Sablotron inside of the
> error
> handling functions!
>
> Code For the Sablotron extension to PHP4 is available through CVS to PHP or you
> can access it online from LXR:
>
> http://lxr.php.net/source/php4/ext/sablot/sablot.c
> http://lxr.php.net/source/php4/ext/sablot/php_sablot.h
>
> -Sterling
>
> --
> Sterling Hughes
> [EMAIL PROTECTED]
>
> > Hi Stefan,
> >
> > It is fortunately that he submited before I do.
> >
> > For for information, I did however apply for a cvs access long time ago
> > (requested by andi) but have not heard anything since. I did my best but maybe
> > someone else has their/his own plan. I obviously am not very happy about it. I
> > cannot do anything about it, can I?
> >
> > Regards,
> >
> > Steven
> >
> >
> > Quoting Stefan Livieratos <[EMAIL PROTECTED]>:
> >
> > > Hi,
> > >
> > > in case you didn't notice:
> > >
> > > Sterling Hughes <[EMAIL PROTECTED]> wrote a (new) PHP Sablot
> > > extension which he commited to the PHP CVS tree yesterday.
> > >
> > > Apart from wrappers for Sablotron's processing functions
> > > the extension includes a SAX interface for expat and
> > > "output buffering tie-ins" so that one can use Sablotron to process
> > > the output of the PHP script directly.
> > >
> > > Regards,
> > > Stefan Livieratos
> > >
> >
> >
> > -------------------------------------------------
> > This mail sent through IMP: pc245.das.com.hk
> >
