james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthieu Baechler <mbaech...@linagora.com>
Subject Re: server/data/data-memory (was : Re: My thoughts on JMAP implementation)
Date Thu, 17 Dec 2015 09:31:24 GMT


On 14/12/2015 10:56, Benoit Tellier wrote:
> In my JAMES-1618 PR I introduced an imMemory UsersRepository (as I
> wanted to test SieveRepository integration).
>
> Le 14/12/2015 08:45, Matthieu Baechler a écrit :
>>
>>
>> On 13/12/2015 12:43, Tellier Benoit wrote:
>>
>>>    - Why not introducing /server/data/data-memory for your
>>> MemoryAccessTokenRepository ? I have upcoming commits to create the
>>> project, maybe moving it to data-memory would make sens.
>>
>> The only rational for not doing it yet is to avoid project
>> proliferation. We only have a single class in data-jmap for in-memory
>> implementation.
>>
>> If you create a server/data/data-memory project, we can put
>> MemoryAccessTokenRepository in it, that's cool.
>>
>
> I want to ask a really stupid question : "Is project proliferation a bad
> thing?"

It is.

Ask yourself if you want to create a Class for every method you need. 
It's probably a good think to segregate responsibilities and reuse 
everything, but it's not very convenient as it trades developer 
efficiency (you need to manage a lot of classes) for modularity.

I see maven modules the same way : we need them to split things, have a 
clear architecture, etc, but in the end, too much modules add to the 
confusion. It's just a matter of balance.

>   - What we pay is time to run tests and compile. Small projects that
> take ~ 2 s to compile do not seem that expensive.

I will slow up dependency resolution, graph construction, run (because 
of classpath size), etc. There's a real cost at this.

>   - If projects are well organized in a hierarchical structure, we are
> not lost, as we can redirect our selves to the right project.

Well organized is not compatible with "too much".

>   - We should pay attention to code duplication (more on that in my next
> mail )

It's when creating modules start to make sense : when there's common 
need in different existing modules

>   - What is dangerous is project for backends nobody is able / volontary
> to maintain...

It's armful too, but that another subjet IMO.

-- 
Matthieu Baechler


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message