Dear Eduardo,

The project is certainly very ambitious. In order to build
a robust and scalable multithreading layer you should be
aware that you will need some knowledge about
system and multi-task programming. Libthread
is a good basis for that and in many respects better than the
aolserver threads. Be also aware, that there is a certain
amount of knowledge about the dependencies of the
base components built into C (pooling, queuing, parsing,
caching, coding, ...). The coroutine model from
tcl 8.6 used in Wub imposes its own structures.

Your first objective is to " OpenACS code to run outside
of AOLServer using only tclsh". Well, if you are
so far, that your are nearly finished. I would say,
the first steps should be a thorough feasibility study
based on the preexisting work (portable.nsd) together
with selective component benchmarks, then
a concept for the overall architecture and the parts
you might be able to finish this summer.

Don't underestimate the work: i was developing
a compatiblity layer for OpenACS to run on
current naviserver. This layer was already
quite some work, and it proved that a simple layering
is not always the best approach (we quickly went
into a mutex locking contention problem due to
changed ns_caching semantics).

If you define smaller steps, your proposal gets more
credibility.

All the best
-gustaf neumann

Am 09.04.10 13:58, schrieb Eduardo Santos:
Hi Matthew,

Thank you very much for your comments. I guess it's better if we keep the talk on the list, so other people can participate. But feel free to do it anyway you want.

I've tried not to be too ambitious for the Summer, concerning it was one of my errors from the last year application. The thing is that I'm trusting, maybe too much, in the work done by the portable.nsd project. In their page (http://www.jsequeira.com/projects/portable.nsd/) they say that they could successfully rewrite the ns_* api to be pure Tcl, mostly running in tclsh. If they have already changed that, and if Wub really works for the HTTP request handling, my real work will be to update the portable.nsd code and replace the request handling code by the Wub API's.

If everything goes right on this way, I think I can make the Job. However, if during the documentation and code analysis I see that it's not possible to reuse any of the components, then I know I'll not see OpenACS working out of AOLServer by the end of Summer. Of course, my goal is to run only the core and not testing any other packages,

Maybe I'm too optimistic on these other woks?

2010/4/8 Matthew M. Burke <mmburke@gwu.edu>
Eduardo,

I thought I'd write you on-list rather than add a comment to the
proposal since I think several other people might also be interested.

What you have proposed seems fairly ambitious for the summer and in
particular I was wondering why you have included working through the
details of OpenACS?

I know the goal is to be able to run OpenACS without using AOLserver,
but you might consider as a first step writing some simpler applications
using the AOLserver API and using those as your testbed.

Matt



------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Tcl-gsoc mailing list
Tcl-gsoc@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-gsoc



--
Eduardo Santos
Analista de Sistemas

http://eduardosan.wordpress.com
http://twitter.com/eduardosan
------------------------------------------------------------------------------ Download Intel&#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
_______________________________________________ Tcl-gsoc mailing list Tcl-gsoc@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tcl-gsoc