[Owasp-antisamy] Questions about Anti-Samy architecture

Arshan Dabirsiaghi arshan.dabirsiaghi at aspectsecurity.com
Thu Jul 29 11:51:03 EDT 2010

I'd love to take some patches, but probably not all of them. I'll respond point by point.
There is still a demand for 1.4 compability. Over the next year I think most enterprises will have moved on to 1.5 or leapfrog onto 1.6 (a 1.7 release could speed this up), but I still see customers using it. Can anyone on the list share their thoughts on seeing 1.4? Are my customers especially behind?
The SAX version is very fast and and doesn't consume nearly as much memory. There were a few organizations that couldn't tolerate the thrash of creating huge DOM trees and then throwing them away due to the GC involved. The DOM version (the way I prefer if possible) is more malleable. I admit it's a bit odd, but different people use both, and I'm okay with that. 
Regarding IOC: I'd be interested to see what that would look like. If it truly makes things easier while not introducing any more complexity, I'd probably merge it. I haven't found much in the world of IOC that reduces complexity though.
Regarding spaces in code: Sorry about that. It probably won't change though, unless we do a 2.0 release where meaningful diff history won't be important.
Regarding DOM3 APIs: Would that require the bump to 1.5?
Regarding user-supplied ResourceBundle: This is needed. 
Regarding message namespace: This is needed.


From: owasp-antisamy-bounces at lists.owasp.org on behalf of Charles Forsythe
Sent: Thu 7/29/2010 11:29 AM
To: 'owasp-antisamy at lists.owasp.org'
Subject: [Owasp-antisamy] Questions about Anti-Samy architecture

For my project, I have made some modifications to meet some of our requirements.  I'd be interested in contributing generally-useful changes to the project, but I'm not sure about some of the change I'd like to see.  I had some questions about the code base.


*	What is the utility of having a SAX and DOM version of the scan?  Right now, I'm basically calling into the DOM scanner directly, as I have my own DOM edits I need to do. 
*	Is there really that much demand for Java 1.4 compatibility?  I'd prefer a Java 5+ code base.  There are also some code cleanups that would be worthwhile (using spaces instead of hard tabs is one example). 


Note that none of this affects the policy file and its processing.  That is great.  I changed the API (slightly) to make the Anti-Samy processing more extensible without touching the policy file processing.  Adding everyone's ad-hoc requirements as policy file options will quickly make Anti-Samy overcomplicated and difficult to use (a barrier to acceptance).


There are some other changes that would make it easier to embed:


*	Following IOC (inversion of control) configuration design patterns 
*	Using DOM3 APIs instead of directly referencing Xerces classes.  (Not sure how to do HTML instead of XHTML output with that, though.) 
*	Allowing the caller to set the ResourceBundle.  It would also help if the i18n keys had a better namespace, like starting with "antisamy."  The ResourceBundle could use the provided properties file, or it could us something else (we have our own i18n system that we'd prefer.) 


Is anyone interested in these updates/structural changes?  If not, I can fork the code (I'd rather not, for obvious reasons.)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-antisamy/attachments/20100729/ef89e2f9/attachment.html 

More information about the Owasp-antisamy mailing list