From: Eduardo S. <edu...@gm...> - 2010-04-12 17:45:30
|
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 <ne...@wu...> > 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 <mm...@gw...> > >> 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® 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...@li... >> https://lists.sourceforge.net/lists/listinfo/tcl-gsoc >> > > > > -- > Eduardo Santos > Analista de Sistemas > > http://eduardosan.wordpress.com > http://twitter.com/eduardosan > > > ------------------------------------------------------------------------------ > Download Intel® 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 lis...@li...https://lists.sourceforge.net/lists/listinfo/tcl-gsoc > > > -- Eduardo Santos Analista de Sistemas http://eduardosan.wordpress.com http://twitter.com/eduardosan |