Garrett Rooney wrote: > [snip] > Agreed, this needs to get resolved. Personally, I'm in favor of > reducing our total number of dependencies, so if we can implement a > parser that doesn't pull in Axiom I'd be all for it. On the other > hand, if we do that by essentially duplicating all of Axiom, that > would be unfortunate. >
I definitely think we'd end up duplicating a large part of Axiom. The real problem I have with Axiom is that it contains a bunch of stuff we really don't need (the SOAP stuff). Perhaps the better approach would be to work with that group to figure out a more convenient packaging so we don't have to ship the stuff we're not using. > [snip] > Things that have occurred to me: > > * A mod_speedyfeed like Servlet filter that implements the A-IM: feed > stuff, so you can automagically drop entries that the requester has > already seen. > Hmm.. that's definitely a possibility but it could get fairly complicated depending on how its implemented. I think we'd need to figure out the larger server module strategy first. > * Better docs/more examples. > > * Improve the ant based build system, maybe pulling in Ivy to do the > dependency management. > > * Finish making sure the test cases don't go out and talk to the > internet, consider pulling the feed validator tests into the tree now > that Sam has updated their license to make that possible. > All definite +1's > * .NET, C++, other implementations of the APIs > I would definitely like to see .NET and C++ implementations. I just have absolutely no time to devote to the actual code. - James
