On 1/11/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Mittwoch, den 10.01.2007, 20:50 +0000 schrieb robert burrell donkin:
<snip>
> > In fact sessions bring a bit inconvenience for the developer. But in the > > past stateless MailRepositories made problems. They were solved by > > putting it into a weak hash map. It's no good practice to let the GC > > decide about sessions. :-) > > IMHO one of the problems with the current API is a lack of clarity about state > > some state is conversational, other state is more naturally associated > with the actual mailbox and could be reasonably shared between > clients. What do you have in mind?
the classic recipe is to store state in the most appropriate place and then pass the state backwards as additional input parameters. this allows each layer to operate more and more concurrently with less and less state.
IMO the implementation, that was written for a certain backend with a certain purpose, can decide perfectly how to handle this.
there are different ways to achieve this goal the current API is overly large and coupled. it is perfectly possible for two tightly coupled systems to operate on either side of a reasonably general API. (usually means switching to a messaging style API.) <snip>
> the inheritance hierarchy seems overly deep to me (both in the > interfaces and the implementation). perhaps this is a sign that the > API would benefit from additional layering. Can you elaborate additional layering?
not sure: it's just usually the right refactoring when faced with this situation :-) it's hard for understand an API with so much inheritance and so many small interfaces. perhaps a protocol layer somewhere might help or maybe a more distinct mailbox layer - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
