FWIW, here's my input...
> Now that 0.2.0 is out the door, here's what I'm thinking for 0.3.0
>
> * I'd like to separate out the IRI stuff into it's own project as was
> recently discussed.
+1
I haven't found any evidence of IRI support in .NET so, whether it's
in Abdera or another project, my guess is it will need to be
implemented as well.
> * I'd like to review the use of Axiom and decide once and for all
> whether or not we're going to keep it or ditch it. If we keep it,
> we should update to the latest release. If we ditch it, we need
> to come up with an alternative.
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've been studying the Axiom code as there's no equivalent in .NET, so
an incremental parser will be a large part of work for a .NET
implementation. This prompts me to consider the pros/cons to such a
parser when there's built-in support for XML object serialization.
But that's another conversation...
So I'm a "0" on this one ;-)
> * We need to figure out what's going on with the server code. I
> haven't had the time to put significant effort into evolving it.
> One option (which I prefer) would be to separate the Server code out
> into its own project and put together a full APP server
> implementation. I have some thoughts on how this could work and
> we may be able to leverage some work that was done with Lucene a
> while back.
Agreed that something needs to get done here, but I'm not sure what.
> * Hopefully the APP spec will be finalized in the next month or so.
> We'll need to finalize the client support.
>
> * The HTTP caching support in the client needs to be thoroughly tested
> and finished (e.g. it currently does not support the Vary header).
> I'm sure there is room for significant improvement in the client
> module.
>
> * What else do we want to do?
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.
* 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.
* .NET, C++, other implementations of the APIs
Obviously, I'm +1 on a .NET implementation. I found someone who is
working on an APP implementation, but it isn't *nearly* as robust as
Abdera (not to discredit the author[s]).
Anyway, those are just random idea, and I have no idea when I'll be
able to work on any of them ;-)
Is there any other interest in working on a .NET implementation? I'm
curious to see if there's anyone else following Abdera with experience
with that framework (or looking to learn it).
- Harris
