[Owasp-antisamy] Questions about Anti-Samy architecture

Charles Forsythe cforsythe at hotels.com
Fri Jul 30 14:10:38 EDT 2010

Thank to everyone for the feedback.

> There is still a demand for 1.4 compability.

I can believe that.  It's pretty sad, seeing as how Sun EOL'ed 1.4 a year and a half ago, but admittedly, we still have a system stuck at 1.4 because of a commercial component that isn't worth the cost to upgrade.

> The SAX version is very fast and and doesn't consume nearly as much 
> memory.

That makes sense.  Perhaps, then, there should be different APIs for SAX and DOC approaches that allow people to take better advantage of each.  Right now, there is a unified API and it's a bit ponderous.  I have to stream my data from a file or socket and write it to a string; then I pass it to a class that turns around and makes it back into a stream.  Allowing callers to pass in a stream directly would make the SAX scanner that much more memory-efficient.

On the DOM side, if callers to the DOM version could also be responsible for parsing their own DOM, it would obviate the need for "pluggable" parsing.  Sample code based on Neko could be provided to give people a "quick-start."

> Regarding IOC: I'd be interested to see what that would look like.

Me, too. :-) I'm not really settled on my integration, so I'm not sure what will turn out to be generally useful and what will just be good for my project.

What I'm thinking is that maybe I could make a "Java 5/New API wrapper" around the current AntiSamy implementation.  It would be inefficient, but it might serve as a good straw-man implementation of a 2.0 version.  I'll do this when I've finished iterating on my project.

In the meantime, I'll try to make some time to do those i18n changes and submit them.

More information about the Owasp-antisamy mailing list