Re: An idea: separating out all the server stuff

[Thomas Koch <th...@koch.ro>]

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

Re: An idea: separating out all the server stuff

[James M Snell <ja...@gmail.com>]

Indeed... at the time, when Abdera first emerged, many of these other
projects were still in early development and it wasn't clear how
things were going to evolve.  I have no problem at all stepping back
and rethinking the design of the server-side stuff. I've separated out
those bits. We should be able to move forward with just the data
format and client side stuff in Abdera2 for now and allow the server
stuff to evolve independently.

On Thu, Feb 2, 2012 at 10:28 AM, Thomas Koch <th...@koch.ro> wrote:
> 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