Hi Gustaf,

Thank you very much for your answer, and sorry for the delay. I was offine in the Weekend. I have a practical doubt right now: should I edit the proposal based on your comments or attach them to the proposal? It's just because I don't know how to put your comments back into the propposal.

Now, let's address the questions individually.

2010/4/9 Gustaf Neumann <neumann@wu-wien.ac.at>
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.

I didn't think about all of that in the first place, like multithreading and this kind of stuff. The idea was to have something running, and leave the performance for other studies.

The caching, pooling and some other things are really something difficult, and my guess would be use Wub in order to help it to happen. I don't know if this is possible, because my time wasn't enough to read all the docs, so maybe I should be more practical on this.
 

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. 

I totally agree with you. The people from the portable.nsd project said that this is already done since 09/2002. If they said the true, everything I have to do is to update the code. Maybe I'm trusting them too much?

 
 

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.

It's a problem that can happen. Maybe there's something I can't see right now harder than I tought in the first place, wich would delay the project. So I should extend the time frame based a more accurate risk analysis?

If I get involved with this project, can you please share your problems with me, so I know the best way to face them?


Thank you very much for the comments again. I hope we can stay in touch.
 

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




--
Eduardo Santos
Analista de Sistemas

http://eduardosan.wordpress.com
http://twitter.com/eduardosan