View previous topic :: View next topic |
Author |
Message |
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Wed May 26, 2004 2:22 pm Post subject: Some things to add to Mango |
|
|
Thought I'd note a couple of ideas that have been floated around:
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?
Perhaps I should mention these in the "potential projects" topic ...
- Kris |
|
Back to top |
|
|
brad Site Admin
Joined: 22 Feb 2004 Posts: 490 Location: Atlanta, GA USA
|
Posted: Wed May 26, 2004 2:55 pm Post subject: |
|
|
I have already tried to port expat a while back, but lack of experience in C and function pointers and .h vagaries stalled me. _________________ I really like the vest! |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Wed May 26, 2004 6:49 pm Post subject: |
|
|
brad wrote: | I have already tried to port expat a while back, but lack of experience in C and function pointers and .h vagaries stalled me. |
Oh, don't let that stop you Brad
- Kris |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Wed May 26, 2004 6:50 pm Post subject: |
|
|
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.
- Kris |
|
Back to top |
|
|
Wienczny
Joined: 10 Apr 2004 Posts: 35
|
Posted: Wed May 26, 2004 8:21 pm Post subject: |
|
|
You could write a native one when Arcane Jill has a working crypto lib... |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Wed May 26, 2004 8:40 pm Post subject: |
|
|
Wienczny wrote: | You could write a native one when Arcane Jill has a working crypto lib... |
Someone could. I don't know enough about the protocol or the certificates, let alone the crypto
Is this something you'd be interested in (in addition to DCC) ?
- Kris |
|
Back to top |
|
|
Wienczny
Joined: 10 Apr 2004 Posts: 35
|
Posted: Fri May 28, 2004 6:32 am Post subject: |
|
|
me either. SSL is a quite complicated protocoll. You will have to support several versions of SSL and TLS.
An open source C implementation is for example openssl. |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Fri May 28, 2004 12:30 pm Post subject: |
|
|
Wienczny wrote: | me either. SSL is a quite complicated protocoll. You will have to support several versions of SSL and TLS.
An open source C implementation is for example openssl. |
Cheers. If anyone's up for tackling an openSSL binding, here's a link that references two very useful PDF howto files: http://www.rtfm.com/openssl-examples/
- Kris |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Fri May 28, 2004 2:47 pm Post subject: |
|
|
There's a few mango.io methods that aren't implemented on linux. Specifically, they include the following:
mango.io.FileConduit.truncate()
mango.io.FileConduit.createMappedBuffer()
mango.io.FileProxy.toList() Anyone have the time/interest/inclination to patch those?
- Kris |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Fri May 28, 2004 2:52 pm Post subject: |
|
|
Also, it would be handy to add a new method
mango.io.FileProxy.rename() to perform an in-place rename only, as opposed to a move.
- Kris |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Tue Jul 06, 2004 12:59 am Post subject: |
|
|
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).
Do you have experience with this kind of thing? Would you be willing to add it into mango.cache? |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Sat Jul 10, 2004 10:19 pm Post subject: |
|
|
kris wrote: | 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.
_________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Sun Jul 11, 2004 12:50 am Post subject: |
|
|
pragma wrote: | kris wrote: | 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 ... |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Sun Jul 11, 2004 2:26 am Post subject: |
|
|
pragma wrote: | 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 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? |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Sun Jul 11, 2004 8:01 am Post subject: |
|
|
kris wrote: |
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.
- readwritelock.d
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:
- Java/OSS Distributed Cache Solutions
kris wrote: |
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 |
|
Back to top |
|
|
|