1) it would be great to have a content-delivery package built on top of the servlet engine. What immediately comes to mind is a port or binding of WebMacro, or perhaps the binding of something like Tea. That would be a killer project.

2) the servlet engine could use an external configuration facility. I've avoided this since it might ostensibly require an XML parser. If someone was up for porting Expat (or similar) that would be really cool!

3) the servlet engine needs a dynamic loader option. Maybe the upcoming Phobos loader will do the trick?

HTTPS support in the server would be really cool, and Mango.server is built with such things in mind. I seem to recall there's a couple of open-source C implementations, but the names escape me right now.

Mango.cache could use a good hashmap implementation; once that explicitly supports concurrent reading whilst writing (many of the former, only one of the latter).

Personally, I feel that there should be a read/write locked cache or one that uses a writer-preference read/write lock rather than just a 'synchronized' cache. It would be a big boon for heavily multithreaded apps that spend more time sifting through the cache than making changes to it.

Also, Dictionary could desperately use a "clear" method. Right now, the only way to do this is 'manually' by building a foreach and calling 'delete' on each key.

I'm still learning how to use Mango to the fullest on DSP, but so far the library has helped tremendously.

Mango.cache could use a good hashmap implementation; once that explicitly supports concurrent reading whilst writing (many of the former, only one of the latter).

Personally, I feel that there should be a read/write locked cache or one that uses a writer-preference read/write lock rather than just a 'synchronized' cache. It would be a big boon for heavily multithreaded apps that spend more time sifting through the cache than making changes to it.

Also, Dictionary could desperately use a "clear" method. Right now, the only way to do this is 'manually' by building a foreach and calling 'delete' on each key.

Agreed, on both counts. I'll add the latter right away, but the former? I've looked at some concurrent hashmaps over the last few days but have yet to find one that is obviously a great choice. Do you know of a really good one Eric? Just to complicate things a tad, the interface would preferably be compatable with the notion of a distributed network cache.

pragma wrote:

I'm still learning how to use Mango to the fullest on DSP, but so far the library has helped tremendously

Glad you find it useful! Still needs a lot of work though, so helping hands are always welcome. Personally, I'll be very happy to see DSP sitting on top. Do you need support for distributed sessions? If so, to what degree? Or would you typically stuff everything into a cookie? Sometimes it's hard to know where to strike a good balance ...

Agreed, on both counts. I'll add the latter right away, but the former? I've looked at some concurrent hashmaps over the last few days but have yet to find one that is obviously a great choice. Do you know of a really good one Eric? Just to complicate things a tad, the interface would preferably be compatable with the notion of a distributed network cache.

The cache interface you have is great, but it just needs a few tweaks to make it concurrent. Concurrent has a really good lock that I used in DSP, that addressed my concerns for the dll cache in V0.0. I plan on using this again for V0.1.

The documentation in the source uses a contrived cache implementation to illustrate the usefulness of a reentrant read/write lock with writer preference (ReentrantWriterPreferenceReadWriteLock). This way, threads only block one another from reading the cache if it is being modified.

I wouldn't know, for the life of me, where to begin making suggestions for a network-distributed cache design. The more I work inside this problem domain, the more I find that I need to learn.

However, google turned up this link with a whole shload of existing Java distributed-cache projects. I've already learned a few things by clicking around in here:

Glad you find it useful! Still needs a lot of work though, so helping hands are always welcome. Personally, I'll be very happy to see DSP sitting on top. Do you need support for distributed sessions? If so, to what degree? Or would you typically stuff everything into a cookie? Sometimes it's hard to know where to strike a good balance ...

I'm glad we agree here: I plan on DSP sitting on top of Mango, so it can take advantage of all of Mango's featues with minimal subclassing and intrusion into both designs. DSP really does need session support at some point, but its not crucial at this time. Ideally, I would love to see something that has configurable session types much like Cold Fusion does.

If the ServletProvider were to have a pluggable SessionProvider that would pave the way for all kinds of sessions quite easily. The SessionProvider could be further be pluggable by a Mango conduit for persistence/distribution. Such a pluggable conduit could also accept any conduit used for the client; this could allow cookies to work among other things.

kris wrote:

I added a clear() method using Ben's magic, but then removed it again since it's actually more effective to just create a new Dictionary. Is the latter not feasable for what you are doing Eric?

At first, I thought it would be cake to just throw a new Dictionary instance in. But, take a look at ServletContext. The configuration and attribute dictionaries are both encapsulated as private, so there's no way a subclass could ever assign a new dictionary to either._________________-- !Eric.t.Anderton at gmail