James Snell: > Right now, even tho we do have the various distinct modules that > separate things out rather well, the data format, client and server > code is still pretty much all bundled together. As Thomas Koch has > pointed out, the server stuff is a bit too overly complex and needs > additional work to really boil it down and, honestly, I think there's > been quite a bit of evolution in the server side of things that the > entire approach being taken for the server side code needs to be > reevaluated anyway. However, I don't want that to interfere with us > being able to get the bulk of the new stuff in abdera2 out the door. > So what I'd like to propose is that the server stuff be moved off to > it's own isolated sub-project with an independent release from the > core of the abdera2 code.. which would still focus primarily on the > data formats (atom + activity streams and basic client side api). This > change could be made rather easily and quickly and would allow us to > move more quickly on getting functionality out and usable while > allowing us to continue evolving at a faster pace. > > Whatcha think?
Hi, I'm wondering how much code in abdera-server is a reimplementation of data structures and logic already present in any REST framework like Jersey, Restlet, Apache CXF or Spring MVC?[1] Could abdera-server be made slimmer by reusing code from one of these projects? Could abdera-server become an extension to one of these projects? Would it make sense to wait for JAX-RS 2 implementations? I just noticed, that abdera2-server actually contains relatively few classes and that many classes that I expected to be part of the server package are in apache-common. Best regards, Thomas Koch, http://www.koch.ro
