james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: Repositories (Design suggestion)
Date Fri, 02 May 2003 14:07:08 GMT
Sid Stuart wrote:
> Thanks for the pointer Serge. Fortunately, I can read a Javadoc and 
> figure out how I would  implement something. Past evidence suggests a 
> void between my approach and the approaches of the James team though. 
> Thus my request for how it would be done. My questions are,
> 
>    Would you store the messages in a folder named spooler?

Maybe.  Originally it seemed that was a good idea, but there isn't as 
much of a need to have spools integrate with other implementations, so 
perhaps we just keep these proprietary and make this very performance 
tailored.

>    How will SpoolRepository's "accept (long delay)" method be implemented?

Not even sure if that's the right design approach, leading to your next 
question.

>    Would you use the listener capability to signal the arrival
>    of new messages to the SpoolManager?

Perhaps.  Right now there's a notifyAll() issue with the file 
implementation for the spooler that Noel believes is causing problems. 
Basically I think we need to step back and redesign spools, so we'll 
have to see.

>   My interest is also perked by comments like this from Noel in the 
> message labeled Re:Repositories (Design suggestion) labeled dated 
> 4/30/2003 4:34
> 
>     I'm not sure if it would be usefull to place the     spool folders 
> in this namespace.
>         TBD.  The idea is that a spooler is not         a store, but 
> rather may USE a store.
>         For example, if we used T-spaces, that         provides its own 
> persistence, and so
>         you don't need to replicate it.

Yes, not sure how much we decouple it or not.  We originally thought 
that, but to the first comment, what does this really get you?  We have 
extra data we need to store, we don't need to integrate, it has a 
different API.  Really spoolers might do better to just be 100% 
separately written implementations.

> I've googled the phrase T-space and came up with this link
> http://www.almaden.ibm.com/cs/TSpaces/intro.html
> While this looks like a powerful platform, I don't understand how the 
> licensing will be compatible with the Apache licensing.

I don't know if Noel meant literally that product.  I don't expect to 
contribute to that design effort directly, beyond these high level 
requirements discussion.

-- 
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com


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


Mime
View raw message