Menu
▾
▴
naviserver-devel — Developer discussion
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(53) |
Mar
(62) |
Apr
(88) |
May
(55) |
Jun
(204) |
Jul
(52) |
Aug
|
Sep
(1) |
Oct
(94) |
Nov
(15) |
Dec
(68) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(130) |
Feb
(105) |
Mar
(34) |
Apr
(61) |
May
(41) |
Jun
(92) |
Jul
(176) |
Aug
(102) |
Sep
(247) |
Oct
(69) |
Nov
(32) |
Dec
(140) |
| 2007 |
Jan
(58) |
Feb
(51) |
Mar
(11) |
Apr
(20) |
May
(34) |
Jun
(37) |
Jul
(18) |
Aug
(60) |
Sep
(41) |
Oct
(105) |
Nov
(19) |
Dec
(14) |
| 2008 |
Jan
(3) |
Feb
|
Mar
(7) |
Apr
(5) |
May
(123) |
Jun
(5) |
Jul
(1) |
Aug
(29) |
Sep
(15) |
Oct
(21) |
Nov
(51) |
Dec
(3) |
| 2009 |
Jan
|
Feb
(36) |
Mar
(29) |
Apr
|
May
|
Jun
(7) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
|
Nov
(13) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(9) |
Apr
(11) |
May
(16) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(7) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(92) |
Nov
(28) |
Dec
(16) |
| 2013 |
Jan
(9) |
Feb
(2) |
Mar
|
Apr
(4) |
May
(4) |
Jun
(6) |
Jul
(14) |
Aug
(12) |
Sep
(4) |
Oct
(13) |
Nov
(1) |
Dec
(6) |
| 2014 |
Jan
(23) |
Feb
(19) |
Mar
(10) |
Apr
(14) |
May
(11) |
Jun
(6) |
Jul
(11) |
Aug
(15) |
Sep
(41) |
Oct
(95) |
Nov
(23) |
Dec
(11) |
| 2015 |
Jan
(3) |
Feb
(9) |
Mar
(19) |
Apr
(3) |
May
(1) |
Jun
(3) |
Jul
(11) |
Aug
(1) |
Sep
(15) |
Oct
(5) |
Nov
(2) |
Dec
|
| 2016 |
Jan
(7) |
Feb
(11) |
Mar
(8) |
Apr
(1) |
May
(3) |
Jun
(17) |
Jul
(12) |
Aug
(3) |
Sep
(5) |
Oct
(19) |
Nov
(12) |
Dec
(6) |
| 2017 |
Jan
(30) |
Feb
(23) |
Mar
(12) |
Apr
(32) |
May
(27) |
Jun
(7) |
Jul
(13) |
Aug
(16) |
Sep
(6) |
Oct
(11) |
Nov
|
Dec
(12) |
| 2018 |
Jan
(1) |
Feb
(5) |
Mar
(6) |
Apr
(7) |
May
(23) |
Jun
(3) |
Jul
(2) |
Aug
(1) |
Sep
(6) |
Oct
(6) |
Nov
(10) |
Dec
(3) |
| 2019 |
Jan
(26) |
Feb
(15) |
Mar
(9) |
Apr
|
May
(8) |
Jun
(14) |
Jul
(10) |
Aug
(10) |
Sep
(4) |
Oct
(2) |
Nov
(20) |
Dec
(10) |
| 2020 |
Jan
(10) |
Feb
(14) |
Mar
(29) |
Apr
(11) |
May
(25) |
Jun
(21) |
Jul
(23) |
Aug
(12) |
Sep
(19) |
Oct
(6) |
Nov
(8) |
Dec
(12) |
| 2021 |
Jan
(29) |
Feb
(9) |
Mar
(8) |
Apr
(8) |
May
(2) |
Jun
(2) |
Jul
(9) |
Aug
(9) |
Sep
(3) |
Oct
(4) |
Nov
(12) |
Dec
(13) |
| 2022 |
Jan
(4) |
Feb
|
Mar
(4) |
Apr
(12) |
May
(15) |
Jun
(7) |
Jul
(10) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(8) |
Dec
|
| 2023 |
Jan
(15) |
Feb
|
Mar
(23) |
Apr
(1) |
May
(2) |
Jun
(10) |
Jul
|
Aug
(22) |
Sep
(19) |
Oct
(2) |
Nov
(20) |
Dec
|
| 2024 |
Jan
(1) |
Feb
|
Mar
(16) |
Apr
(15) |
May
(6) |
Jun
(4) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(18) |
Dec
(6) |
| 2025 |
Jan
(12) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
(5) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andrew P. <at...@pi...> - 2007-07-05 20:00:22
|
On Thu, Jul 05, 2007 at 08:18:02PM +0100, Stephen Deasey wrote: > http://sharethis.com/teamBio?tbio=jd > > No more AOLserver updates from Jim? You should just ask him? He could conceivably be using AOLserver, nsdci, or related open source code at the new company. http://code.google.com/p/nsdci/ -- Andrew Piskorski <at...@pi...> http://www.piskorski.com/ |
|
From: Zoran V. <zv...@ar...> - 2007-07-05 19:40:48
|
On 05.07.2007, at 21:18, Stephen Deasey wrote: > http://sharethis.com/teamBio?tbio=jd > > No more AOLserver updates from Jim? Too bad for the project. That explains much of the "silence" on theaolsever's list. We had a good "vision" more than two years ago: 2005-02-15 Zoran Vasiljevic <vas...@us...> --- INITIAL IMPORT OF 4.0.10 AOLSERVER CODE --- I'm more than glad we did it. Well, lets make the best of it :-) Cheers, Zoran |
|
From: Stephen D. <sd...@gm...> - 2007-07-05 19:18:21
|
http://sharethis.com/teamBio?tbio=jd No more AOLserver updates from Jim? |
|
From: Stephen D. <sd...@gm...> - 2007-07-03 21:29:04
|
On 7/3/07, Zoran Vasiljevic <zv...@ar...> wrote: > > On 03.07.2007, at 23:07, Stephen Deasey wrote: > > > > > Is autoconf-2.60 too painful? > > > Did you try to compile Tcl with that (2.60)? > I do not know about Darwin and 2.60 autoconf. > I maybe needing to test that. Only applies if you build Tcl from CVS, right? You can usually install multiple versions of autoconf at the same time. Fedora has autoconf (2.61) and autoconf213 (2.13) available by default. > At the moment I can live with commenting > those out (just did and it passed). So they're at least present on OSX. If they're available on everything we care about there's no point testing... |
|
From: Zoran V. <zv...@ar...> - 2007-07-03 21:14:18
|
On 03.07.2007, at 23:07, Stephen Deasey wrote: > > Is autoconf-2.60 too painful? Did you try to compile Tcl with that (2.60)? I do not know about Darwin and 2.60 autoconf. I maybe needing to test that. At the moment I can live with commenting those out (just did and it passed). Cheers Zoran |
|
From: Stephen D. <sd...@gm...> - 2007-07-03 21:07:08
|
On 7/3/07, Zoran Vasiljevic <zv...@ar...> wrote: > > On 03.07.2007, at 22:03, Stephen Deasey wrote: > > > I think even that is a bad idea as nowhere in the code are they > > actually used. Some external modules make use of them, but that is a > > crazy dependency! > > Hm... if you get them out, nothing will break? > Only modules? > Which modules? You're also going to have trouble with AC_TYPE_INTPTR_T and AC_TYPE_UINTPTR_T. Is autoconf-2.60 too painful? Does a platform we support not have intptr_t and unintptr_t? |
|
From: Stephen D. <sd...@gm...> - 2007-07-03 21:01:18
|
On 7/3/07, Vlad Seryakov <vl...@cr...> wrote: > I will update modules if that is the conclusion The problem with ns_int8 etc. is that there already is a perfectly good name for it. If int8_t does not exist, then the best strategy is to just define that, not some other name. It's basically equivalent. The advantage is that our code becomes more standard and readable. We doe have some ns_whatever code, but that tends to be a more or less functionally identical wrapper which is either thread safe or performs some error handling. Another reason no to overload the ns_* C name space. The AC_TYPE_INT8_T macros handle this -- they check and define their own versions if not present. We need to move towards each module having it's own configure script... |
|
From: Vlad S. <vl...@cr...> - 2007-07-03 20:45:01
|
I will update modules if that is the conclusion Zoran Vasiljevic wrote: > On 03.07.2007, at 22:03, Stephen Deasey wrote: > >> I think even that is a bad idea as nowhere in the code are they >> actually used. Some external modules make use of them, but that is a >> crazy dependency! > > Hm... if you get them out, nothing will break? > Only modules? > Which modules? > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Zoran V. <zv...@ar...> - 2007-07-03 20:41:19
|
On 03.07.2007, at 22:03, Stephen Deasey wrote: > I think even that is a bad idea as nowhere in the code are they > actually used. Some external modules make use of them, but that is a > crazy dependency! Hm... if you get them out, nothing will break? Only modules? Which modules? |
|
From: Stephen D. <sd...@gm...> - 2007-07-03 20:03:20
|
On 7/3/07, Zoran Vasiljevic <zv...@ar...> wrote: > zvpb:~/sf/naviserver zoran$ sh autogen.sh --enable-symbols > Running aclocal -I m4 > Running autoheader > Running autoconf > configure.in:172: error: possibly undefined macro: AC_TYPE_INT8_T > If this token and others are legitimate, please use > m4_pattern_allow. > See the Autoconf documentation. > configure.in:173: error: possibly undefined macro: AC_TYPE_INT16_T > configure.in:174: error: possibly undefined macro: AC_TYPE_INT32_T > configure.in:175: error: possibly undefined macro: AC_TYPE_INT64_T > configure.in:177: error: possibly undefined macro: AC_TYPE_UINT8_T > configure.in:178: error: possibly undefined macro: AC_TYPE_UINT16_T > configure.in:179: error: possibly undefined macro: AC_TYPE_UINT32_T > configure.in:180: error: possibly undefined macro: AC_TYPE_UINT64_T > configure.in:182: error: possibly undefined macro: AC_TYPE_INTMAX_T > configure.in:183: error: possibly undefined macro: AC_TYPE_UINTMAX_T > configure.in:185: error: possibly undefined macro: AC_TYPE_INTPTR_T > configure.in:186: error: possibly undefined macro: AC_TYPE_UINTPTR_T > zvpb:~/sf/naviserver zoran$ autoconf -V > autoconf (GNU Autoconf) 2.59 > Written by David J. MacKenzie and Akim Demaille. > > Copyright (C) 2003 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There > is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > zvpb:~/dev/tcl_macbinary/unix zoran$ uname -a > Darwin zvpb.local 8.9.0 Darwin Kernel Version 8.9.0: Thu Feb 22 > 20:54:07 PST 2007; root:xnu-792.17.14~1/RELEASE_PPC Power Macintosh > powerpc > zvpb:~/sf/naviserver zoran$ > > Any ideas why is this so and where are those defined? Oh. Looks like these were first added to autoconf 2.59c, released 15 months ago. I added these to try and discourage Vlad from defining ns_int16 etc. redundantly :-) I think even that is a bad idea as nowhere in the code are they actually used. Some external modules make use of them, but that is a crazy dependency! |
|
From: Zoran V. <zv...@ar...> - 2007-07-03 19:04:02
|
zvpb:~/sf/naviserver zoran$ sh autogen.sh --enable-symbols
Running aclocal -I m4
Running autoheader
Running autoconf
configure.in:172: error: possibly undefined macro: AC_TYPE_INT8_T
If this token and others are legitimate, please use
m4_pattern_allow.
See the Autoconf documentation.
configure.in:173: error: possibly undefined macro: AC_TYPE_INT16_T
configure.in:174: error: possibly undefined macro: AC_TYPE_INT32_T
configure.in:175: error: possibly undefined macro: AC_TYPE_INT64_T
configure.in:177: error: possibly undefined macro: AC_TYPE_UINT8_T
configure.in:178: error: possibly undefined macro: AC_TYPE_UINT16_T
configure.in:179: error: possibly undefined macro: AC_TYPE_UINT32_T
configure.in:180: error: possibly undefined macro: AC_TYPE_UINT64_T
configure.in:182: error: possibly undefined macro: AC_TYPE_INTMAX_T
configure.in:183: error: possibly undefined macro: AC_TYPE_UINTMAX_T
configure.in:185: error: possibly undefined macro: AC_TYPE_INTPTR_T
configure.in:186: error: possibly undefined macro: AC_TYPE_UINTPTR_T
zvpb:~/sf/naviserver zoran$ autoconf -V
autoconf (GNU Autoconf) 2.59
Written by David J. MacKenzie and Akim Demaille.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
zvpb:~/dev/tcl_macbinary/unix zoran$ uname -a
Darwin zvpb.local 8.9.0 Darwin Kernel Version 8.9.0: Thu Feb 22
20:54:07 PST 2007; root:xnu-792.17.14~1/RELEASE_PPC Power Macintosh
powerpc
zvpb:~/sf/naviserver zoran$
Any ideas why is this so and where are those defined?
Cheers,
Zoran
|
|
From: sqqwe <ww...@ya...> - 2007-07-02 13:36:54
|
企业中高收入者的薪酬奖金纳税(避税)筹划
2007年7月20日 北京新兴宾馆
2007年7月21日 深圳金融培训中心
2007年7月28日 上海新梅华东
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⊙主 办单位：众 人 行 管 理 咨 询
⊙培 训价格： 1 3 0 0元 / 人
⊙电 话： 0755/26075429 26075265
⊙传 真： 0755/61351396
⊙联 系 人： 彭小姐
★课程背景：
偷税漏税可耻，且为法律所不容，但作为纳税人，您每年都要因为支付工资奖
金而交纳很大数额的个人所得税和企业所得税。您是否想过，在您交纳的税额中，
有相当大的部分是可以通过有效地避税筹划方法而合法、合理地免除的？
合法避税是指在尊重税法、依法纳税的前提下，纳税人采取适当的手段对纳税
义务的规避，减少税务上的支出。
2月6日，全国人大常委会副委员长成思危在中国税务报社主办的“关注中国税
收”系列发布会上表示，目前国内对合法避税的争议较多，但只要是在法律规定的
框架内操作，应该是可以的。
新《个人所得税法实施条例》执行以来，大大增加了企业管理、营销和技术骨
干及外籍人士等中高收入者的税负！而且，国家税务总局近日发布的《个人所得
税自行纳税申报办法(试行)》表明国家正在采取更为严厉的政策和措施，以加强
对中高收入者的税收征管，并由此直接影响到企业所得税！因此，掌握合理、合
法的避税方法及技巧是十分必要的，因为这将大大减轻您的税负，从而有效地避
免您个人的经济损失并增加企业的效益！
★您将主要从以下几个方面受益：
-专家将根据最新的税收征管动向，帮您建立合法有效的个税避税思路及方案！
-通过多种实用避税方法，大大减轻贵公司管理、营销和技术骨干及外籍人士等
中高收入者的税负！
-专家还将为您提供一系列降低工资费用相关的企业所得税的避税方案，以增加
企业的经济效益！
-专家将结合精选案例进行授课，并且现场答疑解惑，解决您工作中的棘手问题！
-有机会与同行就共同的问题进行交流并从中受益！
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
★课程大纲:
一、最新个人所得税法规定及其对中高收入者的影响
(一）实体法――影响中高收入者应纳个人所得税额计算的最新规定
（二）程序法――影响中高收入者个人所得税征收管理的最新规定
1、个人所得税自行纳税申报办法（试行）
2、个人所得税全员全额扣缴申报管理暂行办法
3、个人所得税征管中被重点监控的行业和个人
4、个人所得税专项检查工作规程
（三）最新税法规定对中高收入者的影响
二、最新企业职工薪酬规定
（一）企业所得税前列支职工薪酬的最新规定
（二）企业会计准则第9号――职工薪酬
三、对纳税筹划的基本理论认识
（一）什么是纳税筹划
（二）纳税筹划的性质？特点
（三）中高收入者开展纳税筹划的前提条件
（四）中高收入者开展纳税筹划应遵循的原则
（五）中高收入者开展纳税筹划应注意哪些问题
（六）合理纳税与避税---你的纳税筹划意识如何
四、中高收入者工资薪酬的纳税筹划思路及案例
（一）纳税人的筹划
（二）税种的筹划
（三）选择计税方法的筹划
（四）征税项目的筹划
（五）减少计税依据的筹划
（六）降低适用税率的筹划
五、中高收入者工资薪金的个人所得税筹划方法及案例
（一）工资薪金福利化、减少名义工资的筹划
（二）工资均衡发放的筹划
（三）年终一次性奖金发放的筹划
（四）奖金发放时间的筹划
（五）包干奖金发放的筹划
（六）工资薪酬制度的筹划
（七）多处取得工资的筹划
六、中高收入者劳务报酬的个税税收筹划及案例
（一）劳务报酬计税的基本规定
（二）降低名义劳务报酬收入的筹划
（三）劳务报酬项目的筹划
（四）合理安排劳务报酬次数的筹划
（五）董事费的税收筹划
七、工资费用的企业所得税筹划
（一) 企业所得税前工资薪金列支的规定
（二）工资税前列支方式的企业所得税筹划
（三）研发人员工资费用的企业所得税筹划
（四）工资核算方式的企业所得税筹划
（五）充分利用工资外费用的企业所得税筹划
（六）企业年金的企业所得税筹划
（七）补充保险的企业所得税筹划
（八）费用项目合理转换的企业所得税筹划
八.外籍个人的个人所得税筹划
(一)外籍个人纳税义务的认定
(二)外籍个人住所转变的税收筹划
(三)外籍个人出境时间的税收筹划
(四)外籍个人工资支付地的税收筹划
(五)外籍个人工资来源地转变的税收筹划
(六)充分利用免税补贴
(七)合理安排工资奖金发放方案
(八)合理处理奖金与红利的关系
(九)外籍个人社会保险会的税收筹划
九、中高收入者其他收入的纳税筹划
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
★ 讲师介绍:
张老师，某财经大学财税学院副教授，注册会计师，注册税师;长期从事税收政策
及理论的教学研究工作，对中国税制，税务代理与实务，税收会计，税务检查有较熟
悉认识和实践操作经验，曾为圣戈班、住友电工、华润科技、小天鹅、利纳马汽车系
统、康奈可汽车电子、三洋电子、复旦复华、相信制动系统、英莳精密科技等数百家
企业及会计提供过税务、税务筹划方面的培训及咨询服务。
陈老师,注册税务师、会计师、律师。中国税务律师、财税（法律）高级讲师、资
深税务筹划专家、税务（法律）综合顾问。从事税政、稽查、律师工作20余年。主要
研究领域：税收政策的研究与执行、税务审计、财税代理、财税顾问、纳税筹划、税
务行政复议或诉讼等。先后出版《企业最新实用增值税法规及所得税汇缴实务热点、
难点问题解读讲议》、《企业所得税的会计控制与纳税筹划讲议》、《进出口生产
（贸易）企业税收操作实务》、《外资企业再投资退税、免抵税及进口设备免税操作
指南》等。陈老师被喻为“财税培训的演讲家”、“财税与法律完美结合的化身”，
他以自己工作实践中的案例演示税法精髓，真实、生动，影响深刻。全国各地受其培
训的学员一致认为：陈老师学识渊博且富有实战经验，能现场及时解难释疑；课程应
用性强，系统、生动有趣；条理清楚、思路清晰、把财税与法律较完美的结合，有独
到的见解。
|
|
From: Vlad S. <vl...@cr...> - 2007-06-29 23:50:20
|
no problem Stephen Deasey wrote: > On 6/30/07, Vlad Seryakov <vl...@cr...> wrote: >> yes, all those cache/nocache and other weird optinos came with old >> naviserver and some parts from new AS 4.5. It needs cleanup. > > > Oh, forgot to ask. The -tcl option you added to ns_adp_include and > ns_adp_parse, was this just for completeness during implementation or > is this actually useful? > > You've never been able to do this with Tcl pages before, so it's not a > backwards compatible thing. > > I think it would be really tricky to use this correctly. ADP pages > have a buffer which is written into with ns_adp_append, ns_adp_puts, > or conceptually with the text outside of <% %> tags. Tcl pages do not > use that buffer, you write directly with ns_return, ns_write, etc. > The two will not play together. > > How would you use ns_adp_include -tcl myfile.tcl ? > > The only thing I can think of is within an ADP page you want to > include another page that is basically all Tcl script and you don't > want to put <% at the very beginning and %> at the very end. > > It hardly seems worth it for the potential confusion. Can I remove the > -tcl option or is there something I'm overlooking? > > >> But i do not like new AS 4.5 config syntax, looks ugly >> >> Stephen Deasey wrote: >>> ns_adp_include takes the new -cache and -nocache options. -nocache is >>> a boolean which suppresses caching. -cache takes an integer number of >>> seconds which is the amount of time the result of evaluating the ADP >>> code should be cached. >>> >>> I think a better name for -cache would be -expires. We already use >>> this terminology for ns_cache_eval and friends. -cache and -nocache >>> look like two opposite boolean states, but cache actually takes an >>> argument of seconds. >>> >>> (Hmm, do we need -nocache? Should -expires 0 mean 'no-cache', expires >>> immediately, or does that look like 'never-expires'?) >>> >>> Currently you pass a TTL to -cache, the time to live in seconds. >>> -expires should support that. But it should also accept an absolute >>> time in the future for consistency with -timeout etc., the semantics >>> of which we've discussed in the past. >>> >>> >>> ns_register_adp and ns_register_tcl also take a -cache option, which >>> should also be changed (I added these, taking the lead from >>> ns_adp_include). Interestingly AOLserver 4.5 has changed the config >>> file syntax for marking which pages should be parsed as ADP: >>> >>> ns_section "ns/server/server1/adp" >>> ns_param map [list /yada/*.adp 1200] >>> >>> The page can now be a two element list with the second element being a >>> ttl. With the -cache option to ns_register_adp (which AOLserver >>> doesn't have) this config style can be neatly handled here: >>> >>> http://naviserver.cvs.sourceforge.net/naviserver/naviserver/tcl/config.tcl?revision=1.2&view=markup#l_123 >>> >>> But here's the question: would it be better to add -expires to >>> ns_limits? It already handles -timeout. >>> >>> http://www.crystalballinc.com/vlad/software/naviserver/files/mann/ns_limits.html >>> >>> I wasn't sure at first but it's making more sense the more I think >>> about it. The -expires limit would be a hint to any command which has >>> some caching ability to, if not explicitly given a value, use the >>> expiry from the per-url limit. >>> >>> Does this make sense? >>> >>> I ask this now because it changes API. For the future, it might be >>> nice (and seems easy enough) to also add HTTP caching headers to the >>> output if an expiry is given. So, not only do we output cache, but the >>> browser won't bother sending if-modified-since requests. >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by DB2 Express >>> Download DB2 Express C - the FREE version of DB2 express and take >>> control of your XML. No limits. Just data. Click to get it now. >>> http://sourceforge.net/powerbar/db2/ >>> _______________________________________________ >>> naviserver-devel mailing list >>> nav...@li... >>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >>> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> naviserver-devel mailing list >> nav...@li... >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Stephen D. <sd...@gm...> - 2007-06-29 23:25:47
|
On 6/30/07, Vlad Seryakov <vl...@cr...> wrote: > yes, all those cache/nocache and other weird optinos came with old > naviserver and some parts from new AS 4.5. It needs cleanup. Oh, forgot to ask. The -tcl option you added to ns_adp_include and ns_adp_parse, was this just for completeness during implementation or is this actually useful? You've never been able to do this with Tcl pages before, so it's not a backwards compatible thing. I think it would be really tricky to use this correctly. ADP pages have a buffer which is written into with ns_adp_append, ns_adp_puts, or conceptually with the text outside of <% %> tags. Tcl pages do not use that buffer, you write directly with ns_return, ns_write, etc. The two will not play together. How would you use ns_adp_include -tcl myfile.tcl ? The only thing I can think of is within an ADP page you want to include another page that is basically all Tcl script and you don't want to put <% at the very beginning and %> at the very end. It hardly seems worth it for the potential confusion. Can I remove the -tcl option or is there something I'm overlooking? > But i do not like new AS 4.5 config syntax, looks ugly > > Stephen Deasey wrote: > > ns_adp_include takes the new -cache and -nocache options. -nocache is > > a boolean which suppresses caching. -cache takes an integer number of > > seconds which is the amount of time the result of evaluating the ADP > > code should be cached. > > > > I think a better name for -cache would be -expires. We already use > > this terminology for ns_cache_eval and friends. -cache and -nocache > > look like two opposite boolean states, but cache actually takes an > > argument of seconds. > > > > (Hmm, do we need -nocache? Should -expires 0 mean 'no-cache', expires > > immediately, or does that look like 'never-expires'?) > > > > Currently you pass a TTL to -cache, the time to live in seconds. > > -expires should support that. But it should also accept an absolute > > time in the future for consistency with -timeout etc., the semantics > > of which we've discussed in the past. > > > > > > ns_register_adp and ns_register_tcl also take a -cache option, which > > should also be changed (I added these, taking the lead from > > ns_adp_include). Interestingly AOLserver 4.5 has changed the config > > file syntax for marking which pages should be parsed as ADP: > > > > ns_section "ns/server/server1/adp" > > ns_param map [list /yada/*.adp 1200] > > > > The page can now be a two element list with the second element being a > > ttl. With the -cache option to ns_register_adp (which AOLserver > > doesn't have) this config style can be neatly handled here: > > > > http://naviserver.cvs.sourceforge.net/naviserver/naviserver/tcl/config.tcl?revision=1.2&view=markup#l_123 > > > > But here's the question: would it be better to add -expires to > > ns_limits? It already handles -timeout. > > > > http://www.crystalballinc.com/vlad/software/naviserver/files/mann/ns_limits.html > > > > I wasn't sure at first but it's making more sense the more I think > > about it. The -expires limit would be a hint to any command which has > > some caching ability to, if not explicitly given a value, use the > > expiry from the per-url limit. > > > > Does this make sense? > > > > I ask this now because it changes API. For the future, it might be > > nice (and seems easy enough) to also add HTTP caching headers to the > > output if an expiry is given. So, not only do we output cache, but the > > browser won't bother sending if-modified-since requests. > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > naviserver-devel mailing list > > nav...@li... > > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Vlad S. <vl...@cr...> - 2007-06-29 23:00:40
|
yes, all those cache/nocache and other weird optinos came with old naviserver and some parts from new AS 4.5. It needs cleanup. But i do not like new AS 4.5 config syntax, looks ugly Stephen Deasey wrote: > ns_adp_include takes the new -cache and -nocache options. -nocache is > a boolean which suppresses caching. -cache takes an integer number of > seconds which is the amount of time the result of evaluating the ADP > code should be cached. > > I think a better name for -cache would be -expires. We already use > this terminology for ns_cache_eval and friends. -cache and -nocache > look like two opposite boolean states, but cache actually takes an > argument of seconds. > > (Hmm, do we need -nocache? Should -expires 0 mean 'no-cache', expires > immediately, or does that look like 'never-expires'?) > > Currently you pass a TTL to -cache, the time to live in seconds. > -expires should support that. But it should also accept an absolute > time in the future for consistency with -timeout etc., the semantics > of which we've discussed in the past. > > > ns_register_adp and ns_register_tcl also take a -cache option, which > should also be changed (I added these, taking the lead from > ns_adp_include). Interestingly AOLserver 4.5 has changed the config > file syntax for marking which pages should be parsed as ADP: > > ns_section "ns/server/server1/adp" > ns_param map [list /yada/*.adp 1200] > > The page can now be a two element list with the second element being a > ttl. With the -cache option to ns_register_adp (which AOLserver > doesn't have) this config style can be neatly handled here: > > http://naviserver.cvs.sourceforge.net/naviserver/naviserver/tcl/config.tcl?revision=1.2&view=markup#l_123 > > But here's the question: would it be better to add -expires to > ns_limits? It already handles -timeout. > > http://www.crystalballinc.com/vlad/software/naviserver/files/mann/ns_limits.html > > I wasn't sure at first but it's making more sense the more I think > about it. The -expires limit would be a hint to any command which has > some caching ability to, if not explicitly given a value, use the > expiry from the per-url limit. > > Does this make sense? > > I ask this now because it changes API. For the future, it might be > nice (and seems easy enough) to also add HTTP caching headers to the > output if an expiry is given. So, not only do we output cache, but the > browser won't bother sending if-modified-since requests. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Stephen D. <sd...@gm...> - 2007-06-29 22:55:40
|
ns_adp_include takes the new -cache and -nocache options. -nocache is a boolean which suppresses caching. -cache takes an integer number of seconds which is the amount of time the result of evaluating the ADP code should be cached. I think a better name for -cache would be -expires. We already use this terminology for ns_cache_eval and friends. -cache and -nocache look like two opposite boolean states, but cache actually takes an argument of seconds. (Hmm, do we need -nocache? Should -expires 0 mean 'no-cache', expires immediately, or does that look like 'never-expires'?) Currently you pass a TTL to -cache, the time to live in seconds. -expires should support that. But it should also accept an absolute time in the future for consistency with -timeout etc., the semantics of which we've discussed in the past. ns_register_adp and ns_register_tcl also take a -cache option, which should also be changed (I added these, taking the lead from ns_adp_include). Interestingly AOLserver 4.5 has changed the config file syntax for marking which pages should be parsed as ADP: ns_section "ns/server/server1/adp" ns_param map [list /yada/*.adp 1200] The page can now be a two element list with the second element being a ttl. With the -cache option to ns_register_adp (which AOLserver doesn't have) this config style can be neatly handled here: http://naviserver.cvs.sourceforge.net/naviserver/naviserver/tcl/config.tcl?revision=1.2&view=markup#l_123 But here's the question: would it be better to add -expires to ns_limits? It already handles -timeout. http://www.crystalballinc.com/vlad/software/naviserver/files/mann/ns_limits.html I wasn't sure at first but it's making more sense the more I think about it. The -expires limit would be a hint to any command which has some caching ability to, if not explicitly given a value, use the expiry from the per-url limit. Does this make sense? I ask this now because it changes API. For the future, it might be nice (and seems easy enough) to also add HTTP caching headers to the output if an expiry is given. So, not only do we output cache, but the browser won't bother sending if-modified-since requests. |
|
From: Vlad S. <vl...@cr...> - 2007-06-29 22:02:18
|
Frankly may be because i am doing hundreds things today i missed what needs to be changed. I am for changes:-)) ADP engine is what i've ported from AS 4.5. Stephen Deasey wrote: > On 6/29/07, Vlad Seryakov <vl...@cr...> wrote: >> What are you suggesting? i am not defending what is currently >> implemented but my only concern is backward compatibility, i have too >> many applications running on naviserver and many companies depend on it:-)) > > > I'm not suggesting making any incompatible changes :-) > > You're saying the Tcl page code uses the ADP engine, I'm saying it > doesn't. One of us is confused, and it's quite possibly me because I > find some of the ADP code tricky. > > I've tried to explain but I think I've basically said the same thing > twice so I'm not sure that it's helping. Do you accept what I'm > saying, or is there something I've muddled up? > > >> Stephen Deasey wrote: >>> On 6/29/07, Vlad Seryakov <vl...@cr...> wrote: >>>> That may be not ideal but my goal was to use same engine (ADP) for >>>> caching and keep compatibility. >>> >>> Right, but that's what I'm saying: it's not using the same engine >>> because Tcl pages are handled in a completely different way, but that >>> mechanism is wedged into the ADP engine. >>> >>> >>>> Also, performance-wise this is faster than the old mechanism. >>> >>> I'm confused about which mechanisms are which. I can think of 3: >>> >>> - original mechanism: >>> http://naviserver.cvs.sourceforge.net/naviserver/naviserver/tcl/file.tcl?hideattic=0&view=markup >>> >>> - new mechanism 1 (effectively): page.adp: <% # your whole tcl page goes here %> >>> >>> - new mechanism 2: take above page and make it a proc (sounds exactly >>> like original mechanism actually) >>> >>> Which is better than which other? >>> >>> >>>> Anyway, to cache Tcl files, only proc can give >>>> that ability without re-parsing. >>> >>> Either I'm confused about what's going on or I disagree :-) >>> >>> We have to agree on caching *what*. The thing that's new to ADP is >>> *response* caching -- there has always been page-content-off-the-disk >>> caching and byte-code-that-corresponds-to-page-off-disk caching. >>> That's 3 different things that are being cached. >>> >>> Now, by turning Tcl pages into procs that's just a different way of >>> byte-code caching, which is already fully supported by the ADP engine. >>> >>> The first problem is that this is confusing because you throw the >>> switch for *reponse* caching but what you actually get is a different >>> method of byte-code caching. >>> >>> The second problem is that if turning the code into a proc is >>> noticeably faster than evaluating a Tcl string object, then why is it >>> only available for Tcl pages and not part of the ADP engine itself, as >>> it equally applies to ADP scripts in 'singlescript' mode. >>> >>> And, why is it optional? Response caching changes the semantics of a >>> page, you can't just enable it for everything. But byte-code caching >>> is just a faster way of getting the same result. Why would you ever >>> want to turn this off? >>> >>> >>>> Stephen Deasey wrote: >>>>> There's some new ADP result caching functionality. How does this >>>>> affect Tcl pages which are now executed by the ADP engine? >>>>> >>>>> >>>>> nsd/adpparse.c: NsAdpParse(): >>>>> >>>>> /* >>>>> * Special case when we evalutating Tcl file, we just wrap it as >>>>> * Tcl proc and save in ADP block with cache enabled or >>>>> * just execute the Tcl code in case of cache disabled >>>>> */ >>>>> >>>>> >>>>> nsd/adpeval.c: AdpSource(): >>>>> >>>>> /* >>>>> * Turn off TCL mode after cached result, in caching mode >>>>> * we wrap Tcl file into proc 'adp:filename' and return >>>>> * as result only >>>>> * ns_adp_append {<% adp:filename %>} >>>>> * >>>>> * The output will be cached as result and every time we call >>>>> * that Tcl file, cached command will be executed as long as >>>>> * file is unchanged, if modified then the file will be reloaded, >>>>> * recompiled into same Tcl proc and cached >>>>> */ >>>>> >>>>> >>>>> So when you enable result caching for ADP pages: >>>>> >>>>> ns_section "ns/server/server1/adp" >>>>> ns_param cache true >>>>> >>>>> or, in an adp page: >>>>> >>>>> ns_adp_ctl cache true >>>>> >>>>> or: >>>>> >>>>> ns_adp_include -cache 1200 myfile.adp >>>>> >>>>> what you're saying is after evaluating the script blocks in the adp, >>>>> and then combining them with the text blocks, cache that result and >>>>> don't re-execute the script blocks until the cache expires. >>>>> >>>>> But for Tcl pages something different is going on. The exact same >>>>> config file option enables caching but now it means take the contents >>>>> of the Tcl file, make it the body of a hidden proc, then execute it >>>>> every time the page is called. The output is not cached. >>>>> >>>>> In some respects this is fine. The commands that Tcl pages use: >>>>> ns_return, ns_write etc., aren't in any way hooked up to the guts of >>>>> the ADP code so it would require a some work to make response caching >>>>> work. Something for the future. >>>>> >>>>> My questions are: >>>>> >>>>> - does it make sense to do this extra step of turning the page into a >>>>> proc at all? >>>>> - does it make sense to overload the response caching config options for both? >>>>> >>>>> (and have I read the code right?) >>>>> >>>>> I guess my concern is that it's not obvious what's going on, both in >>>>> terms of configuration and code implementation, and that it's going to >>>>> hurt in the future when we want to add response caching to more parts >>>>> of the code. >>>>> >>>>> I'm also wondering why two different strategies are being used for ADP >>>>> and Tcl pages which are essentially identical. The script blocks for >>>>> an ADP are cached per-interp which allows the byte-code to persist. >>>>> The Tcl pages are turned into procs (but only optionally). >>>>> >>>>> ADP pages have a new 'singlescript' option which combines the text and >>>>> script blocks into a single script block. The intent was to allow code >>>>> to span <% .. %> boundaries, and a side effect is that a single error >>>>> aborts the whole page. But the interesting things is that now it's >>>>> basically a single chunk of Tcl to execute, like a Tcl page. Yet >>>>> they're handled differently... >>>>> >>>>> Also, the constructed procs aren't garbage collected (same problem as >>>>> the old Tcl page code)... >>>>> >>>>> ------------------------------------------------------------------------- >>>>> This SF.net email is sponsored by DB2 Express >>>>> Download DB2 Express C - the FREE version of DB2 express and take >>>>> control of your XML. No limits. Just data. Click to get it now. >>>>> http://sourceforge.net/powerbar/db2/ >>>>> _______________________________________________ >>>>> naviserver-devel mailing list >>>>> nav...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >>>>> >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by DB2 Express >>>> Download DB2 Express C - the FREE version of DB2 express and take >>>> control of your XML. No limits. Just data. Click to get it now. >>>> http://sourceforge.net/powerbar/db2/ >>>> _______________________________________________ >>>> naviserver-devel mailing list >>>> nav...@li... >>>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >>>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by DB2 Express >>> Download DB2 Express C - the FREE version of DB2 express and take >>> control of your XML. No limits. Just data. Click to get it now. >>> http://sourceforge.net/powerbar/db2/ >>> _______________________________________________ >>> naviserver-devel mailing list >>> nav...@li... >>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >>> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> naviserver-devel mailing list >> nav...@li... >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Stephen D. <sd...@gm...> - 2007-06-29 21:57:25
|
On 6/29/07, Vlad Seryakov <vl...@cr...> wrote: > What are you suggesting? i am not defending what is currently > implemented but my only concern is backward compatibility, i have too > many applications running on naviserver and many companies depend on it:-)) I'm not suggesting making any incompatible changes :-) You're saying the Tcl page code uses the ADP engine, I'm saying it doesn't. One of us is confused, and it's quite possibly me because I find some of the ADP code tricky. I've tried to explain but I think I've basically said the same thing twice so I'm not sure that it's helping. Do you accept what I'm saying, or is there something I've muddled up? > Stephen Deasey wrote: > > On 6/29/07, Vlad Seryakov <vl...@cr...> wrote: > >> That may be not ideal but my goal was to use same engine (ADP) for > >> caching and keep compatibility. > > > > > > Right, but that's what I'm saying: it's not using the same engine > > because Tcl pages are handled in a completely different way, but that > > mechanism is wedged into the ADP engine. > > > > > >> Also, performance-wise this is faster than the old mechanism. > > > > > > I'm confused about which mechanisms are which. I can think of 3: > > > > - original mechanism: > > http://naviserver.cvs.sourceforge.net/naviserver/naviserver/tcl/file.tcl?hideattic=0&view=markup > > > > - new mechanism 1 (effectively): page.adp: <% # your whole tcl page goes here %> > > > > - new mechanism 2: take above page and make it a proc (sounds exactly > > like original mechanism actually) > > > > Which is better than which other? > > > > > >> Anyway, to cache Tcl files, only proc can give > >> that ability without re-parsing. > > > > > > Either I'm confused about what's going on or I disagree :-) > > > > We have to agree on caching *what*. The thing that's new to ADP is > > *response* caching -- there has always been page-content-off-the-disk > > caching and byte-code-that-corresponds-to-page-off-disk caching. > > That's 3 different things that are being cached. > > > > Now, by turning Tcl pages into procs that's just a different way of > > byte-code caching, which is already fully supported by the ADP engine. > > > > The first problem is that this is confusing because you throw the > > switch for *reponse* caching but what you actually get is a different > > method of byte-code caching. > > > > The second problem is that if turning the code into a proc is > > noticeably faster than evaluating a Tcl string object, then why is it > > only available for Tcl pages and not part of the ADP engine itself, as > > it equally applies to ADP scripts in 'singlescript' mode. > > > > And, why is it optional? Response caching changes the semantics of a > > page, you can't just enable it for everything. But byte-code caching > > is just a faster way of getting the same result. Why would you ever > > want to turn this off? > > > > > >> Stephen Deasey wrote: > >>> There's some new ADP result caching functionality. How does this > >>> affect Tcl pages which are now executed by the ADP engine? > >>> > >>> > >>> nsd/adpparse.c: NsAdpParse(): > >>> > >>> /* > >>> * Special case when we evalutating Tcl file, we just wrap it as > >>> * Tcl proc and save in ADP block with cache enabled or > >>> * just execute the Tcl code in case of cache disabled > >>> */ > >>> > >>> > >>> nsd/adpeval.c: AdpSource(): > >>> > >>> /* > >>> * Turn off TCL mode after cached result, in caching mode > >>> * we wrap Tcl file into proc 'adp:filename' and return > >>> * as result only > >>> * ns_adp_append {<% adp:filename %>} > >>> * > >>> * The output will be cached as result and every time we call > >>> * that Tcl file, cached command will be executed as long as > >>> * file is unchanged, if modified then the file will be reloaded, > >>> * recompiled into same Tcl proc and cached > >>> */ > >>> > >>> > >>> So when you enable result caching for ADP pages: > >>> > >>> ns_section "ns/server/server1/adp" > >>> ns_param cache true > >>> > >>> or, in an adp page: > >>> > >>> ns_adp_ctl cache true > >>> > >>> or: > >>> > >>> ns_adp_include -cache 1200 myfile.adp > >>> > >>> what you're saying is after evaluating the script blocks in the adp, > >>> and then combining them with the text blocks, cache that result and > >>> don't re-execute the script blocks until the cache expires. > >>> > >>> But for Tcl pages something different is going on. The exact same > >>> config file option enables caching but now it means take the contents > >>> of the Tcl file, make it the body of a hidden proc, then execute it > >>> every time the page is called. The output is not cached. > >>> > >>> In some respects this is fine. The commands that Tcl pages use: > >>> ns_return, ns_write etc., aren't in any way hooked up to the guts of > >>> the ADP code so it would require a some work to make response caching > >>> work. Something for the future. > >>> > >>> My questions are: > >>> > >>> - does it make sense to do this extra step of turning the page into a > >>> proc at all? > >>> - does it make sense to overload the response caching config options for both? > >>> > >>> (and have I read the code right?) > >>> > >>> I guess my concern is that it's not obvious what's going on, both in > >>> terms of configuration and code implementation, and that it's going to > >>> hurt in the future when we want to add response caching to more parts > >>> of the code. > >>> > >>> I'm also wondering why two different strategies are being used for ADP > >>> and Tcl pages which are essentially identical. The script blocks for > >>> an ADP are cached per-interp which allows the byte-code to persist. > >>> The Tcl pages are turned into procs (but only optionally). > >>> > >>> ADP pages have a new 'singlescript' option which combines the text and > >>> script blocks into a single script block. The intent was to allow code > >>> to span <% .. %> boundaries, and a side effect is that a single error > >>> aborts the whole page. But the interesting things is that now it's > >>> basically a single chunk of Tcl to execute, like a Tcl page. Yet > >>> they're handled differently... > >>> > >>> Also, the constructed procs aren't garbage collected (same problem as > >>> the old Tcl page code)... > >>> > >>> ------------------------------------------------------------------------- > >>> This SF.net email is sponsored by DB2 Express > >>> Download DB2 Express C - the FREE version of DB2 express and take > >>> control of your XML. No limits. Just data. Click to get it now. > >>> http://sourceforge.net/powerbar/db2/ > >>> _______________________________________________ > >>> naviserver-devel mailing list > >>> nav...@li... > >>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel > >>> > >> > >> ------------------------------------------------------------------------- > >> This SF.net email is sponsored by DB2 Express > >> Download DB2 Express C - the FREE version of DB2 express and take > >> control of your XML. No limits. Just data. Click to get it now. > >> http://sourceforge.net/powerbar/db2/ > >> _______________________________________________ > >> naviserver-devel mailing list > >> nav...@li... > >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel > >> > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > naviserver-devel mailing list > > nav...@li... > > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Vlad S. <vl...@cr...> - 2007-06-29 21:30:14
|
What are you suggesting? i am not defending what is currently implemented but my only concern is backward compatibility, i have too many applications running on naviserver and many companies depend on it:-)) Stephen Deasey wrote: > On 6/29/07, Vlad Seryakov <vl...@cr...> wrote: >> That may be not ideal but my goal was to use same engine (ADP) for >> caching and keep compatibility. > > > Right, but that's what I'm saying: it's not using the same engine > because Tcl pages are handled in a completely different way, but that > mechanism is wedged into the ADP engine. > > >> Also, performance-wise this is faster than the old mechanism. > > > I'm confused about which mechanisms are which. I can think of 3: > > - original mechanism: > http://naviserver.cvs.sourceforge.net/naviserver/naviserver/tcl/file.tcl?hideattic=0&view=markup > > - new mechanism 1 (effectively): page.adp: <% # your whole tcl page goes here %> > > - new mechanism 2: take above page and make it a proc (sounds exactly > like original mechanism actually) > > Which is better than which other? > > >> Anyway, to cache Tcl files, only proc can give >> that ability without re-parsing. > > > Either I'm confused about what's going on or I disagree :-) > > We have to agree on caching *what*. The thing that's new to ADP is > *response* caching -- there has always been page-content-off-the-disk > caching and byte-code-that-corresponds-to-page-off-disk caching. > That's 3 different things that are being cached. > > Now, by turning Tcl pages into procs that's just a different way of > byte-code caching, which is already fully supported by the ADP engine. > > The first problem is that this is confusing because you throw the > switch for *reponse* caching but what you actually get is a different > method of byte-code caching. > > The second problem is that if turning the code into a proc is > noticeably faster than evaluating a Tcl string object, then why is it > only available for Tcl pages and not part of the ADP engine itself, as > it equally applies to ADP scripts in 'singlescript' mode. > > And, why is it optional? Response caching changes the semantics of a > page, you can't just enable it for everything. But byte-code caching > is just a faster way of getting the same result. Why would you ever > want to turn this off? > > >> Stephen Deasey wrote: >>> There's some new ADP result caching functionality. How does this >>> affect Tcl pages which are now executed by the ADP engine? >>> >>> >>> nsd/adpparse.c: NsAdpParse(): >>> >>> /* >>> * Special case when we evalutating Tcl file, we just wrap it as >>> * Tcl proc and save in ADP block with cache enabled or >>> * just execute the Tcl code in case of cache disabled >>> */ >>> >>> >>> nsd/adpeval.c: AdpSource(): >>> >>> /* >>> * Turn off TCL mode after cached result, in caching mode >>> * we wrap Tcl file into proc 'adp:filename' and return >>> * as result only >>> * ns_adp_append {<% adp:filename %>} >>> * >>> * The output will be cached as result and every time we call >>> * that Tcl file, cached command will be executed as long as >>> * file is unchanged, if modified then the file will be reloaded, >>> * recompiled into same Tcl proc and cached >>> */ >>> >>> >>> So when you enable result caching for ADP pages: >>> >>> ns_section "ns/server/server1/adp" >>> ns_param cache true >>> >>> or, in an adp page: >>> >>> ns_adp_ctl cache true >>> >>> or: >>> >>> ns_adp_include -cache 1200 myfile.adp >>> >>> what you're saying is after evaluating the script blocks in the adp, >>> and then combining them with the text blocks, cache that result and >>> don't re-execute the script blocks until the cache expires. >>> >>> But for Tcl pages something different is going on. The exact same >>> config file option enables caching but now it means take the contents >>> of the Tcl file, make it the body of a hidden proc, then execute it >>> every time the page is called. The output is not cached. >>> >>> In some respects this is fine. The commands that Tcl pages use: >>> ns_return, ns_write etc., aren't in any way hooked up to the guts of >>> the ADP code so it would require a some work to make response caching >>> work. Something for the future. >>> >>> My questions are: >>> >>> - does it make sense to do this extra step of turning the page into a >>> proc at all? >>> - does it make sense to overload the response caching config options for both? >>> >>> (and have I read the code right?) >>> >>> I guess my concern is that it's not obvious what's going on, both in >>> terms of configuration and code implementation, and that it's going to >>> hurt in the future when we want to add response caching to more parts >>> of the code. >>> >>> I'm also wondering why two different strategies are being used for ADP >>> and Tcl pages which are essentially identical. The script blocks for >>> an ADP are cached per-interp which allows the byte-code to persist. >>> The Tcl pages are turned into procs (but only optionally). >>> >>> ADP pages have a new 'singlescript' option which combines the text and >>> script blocks into a single script block. The intent was to allow code >>> to span <% .. %> boundaries, and a side effect is that a single error >>> aborts the whole page. But the interesting things is that now it's >>> basically a single chunk of Tcl to execute, like a Tcl page. Yet >>> they're handled differently... >>> >>> Also, the constructed procs aren't garbage collected (same problem as >>> the old Tcl page code)... >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by DB2 Express >>> Download DB2 Express C - the FREE version of DB2 express and take >>> control of your XML. No limits. Just data. Click to get it now. >>> http://sourceforge.net/powerbar/db2/ >>> _______________________________________________ >>> naviserver-devel mailing list >>> nav...@li... >>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >>> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> naviserver-devel mailing list >> nav...@li... >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Stephen D. <sd...@gm...> - 2007-06-29 20:48:28
|
On 6/29/07, Vlad Seryakov <vl...@cr...> wrote: > That may be not ideal but my goal was to use same engine (ADP) for > caching and keep compatibility. Right, but that's what I'm saying: it's not using the same engine because Tcl pages are handled in a completely different way, but that mechanism is wedged into the ADP engine. > Also, performance-wise this is faster than the old mechanism. I'm confused about which mechanisms are which. I can think of 3: - original mechanism: http://naviserver.cvs.sourceforge.net/naviserver/naviserver/tcl/file.tcl?hideattic=0&view=markup - new mechanism 1 (effectively): page.adp: <% # your whole tcl page goes here %> - new mechanism 2: take above page and make it a proc (sounds exactly like original mechanism actually) Which is better than which other? > Anyway, to cache Tcl files, only proc can give > that ability without re-parsing. Either I'm confused about what's going on or I disagree :-) We have to agree on caching *what*. The thing that's new to ADP is *response* caching -- there has always been page-content-off-the-disk caching and byte-code-that-corresponds-to-page-off-disk caching. That's 3 different things that are being cached. Now, by turning Tcl pages into procs that's just a different way of byte-code caching, which is already fully supported by the ADP engine. The first problem is that this is confusing because you throw the switch for *reponse* caching but what you actually get is a different method of byte-code caching. The second problem is that if turning the code into a proc is noticeably faster than evaluating a Tcl string object, then why is it only available for Tcl pages and not part of the ADP engine itself, as it equally applies to ADP scripts in 'singlescript' mode. And, why is it optional? Response caching changes the semantics of a page, you can't just enable it for everything. But byte-code caching is just a faster way of getting the same result. Why would you ever want to turn this off? > Stephen Deasey wrote: > > There's some new ADP result caching functionality. How does this > > affect Tcl pages which are now executed by the ADP engine? > > > > > > nsd/adpparse.c: NsAdpParse(): > > > > /* > > * Special case when we evalutating Tcl file, we just wrap it as > > * Tcl proc and save in ADP block with cache enabled or > > * just execute the Tcl code in case of cache disabled > > */ > > > > > > nsd/adpeval.c: AdpSource(): > > > > /* > > * Turn off TCL mode after cached result, in caching mode > > * we wrap Tcl file into proc 'adp:filename' and return > > * as result only > > * ns_adp_append {<% adp:filename %>} > > * > > * The output will be cached as result and every time we call > > * that Tcl file, cached command will be executed as long as > > * file is unchanged, if modified then the file will be reloaded, > > * recompiled into same Tcl proc and cached > > */ > > > > > > So when you enable result caching for ADP pages: > > > > ns_section "ns/server/server1/adp" > > ns_param cache true > > > > or, in an adp page: > > > > ns_adp_ctl cache true > > > > or: > > > > ns_adp_include -cache 1200 myfile.adp > > > > what you're saying is after evaluating the script blocks in the adp, > > and then combining them with the text blocks, cache that result and > > don't re-execute the script blocks until the cache expires. > > > > But for Tcl pages something different is going on. The exact same > > config file option enables caching but now it means take the contents > > of the Tcl file, make it the body of a hidden proc, then execute it > > every time the page is called. The output is not cached. > > > > In some respects this is fine. The commands that Tcl pages use: > > ns_return, ns_write etc., aren't in any way hooked up to the guts of > > the ADP code so it would require a some work to make response caching > > work. Something for the future. > > > > My questions are: > > > > - does it make sense to do this extra step of turning the page into a > > proc at all? > > - does it make sense to overload the response caching config options for both? > > > > (and have I read the code right?) > > > > I guess my concern is that it's not obvious what's going on, both in > > terms of configuration and code implementation, and that it's going to > > hurt in the future when we want to add response caching to more parts > > of the code. > > > > I'm also wondering why two different strategies are being used for ADP > > and Tcl pages which are essentially identical. The script blocks for > > an ADP are cached per-interp which allows the byte-code to persist. > > The Tcl pages are turned into procs (but only optionally). > > > > ADP pages have a new 'singlescript' option which combines the text and > > script blocks into a single script block. The intent was to allow code > > to span <% .. %> boundaries, and a side effect is that a single error > > aborts the whole page. But the interesting things is that now it's > > basically a single chunk of Tcl to execute, like a Tcl page. Yet > > they're handled differently... > > > > Also, the constructed procs aren't garbage collected (same problem as > > the old Tcl page code)... > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > naviserver-devel mailing list > > nav...@li... > > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Vlad S. <vl...@cr...> - 2007-06-29 20:13:20
|
That may be not ideal but my goal was to use same engine (ADP) for
caching and keep compatibility. Also, performance-wise this is faster
than the old mechanism. Anyway, to cache Tcl files, only proc can give
that ability without re-parsing.
Stephen Deasey wrote:
> There's some new ADP result caching functionality. How does this
> affect Tcl pages which are now executed by the ADP engine?
>
>
> nsd/adpparse.c: NsAdpParse():
>
> /*
> * Special case when we evalutating Tcl file, we just wrap it as
> * Tcl proc and save in ADP block with cache enabled or
> * just execute the Tcl code in case of cache disabled
> */
>
>
> nsd/adpeval.c: AdpSource():
>
> /*
> * Turn off TCL mode after cached result, in caching mode
> * we wrap Tcl file into proc 'adp:filename' and return
> * as result only
> * ns_adp_append {<% adp:filename %>}
> *
> * The output will be cached as result and every time we call
> * that Tcl file, cached command will be executed as long as
> * file is unchanged, if modified then the file will be reloaded,
> * recompiled into same Tcl proc and cached
> */
>
>
> So when you enable result caching for ADP pages:
>
> ns_section "ns/server/server1/adp"
> ns_param cache true
>
> or, in an adp page:
>
> ns_adp_ctl cache true
>
> or:
>
> ns_adp_include -cache 1200 myfile.adp
>
> what you're saying is after evaluating the script blocks in the adp,
> and then combining them with the text blocks, cache that result and
> don't re-execute the script blocks until the cache expires.
>
> But for Tcl pages something different is going on. The exact same
> config file option enables caching but now it means take the contents
> of the Tcl file, make it the body of a hidden proc, then execute it
> every time the page is called. The output is not cached.
>
> In some respects this is fine. The commands that Tcl pages use:
> ns_return, ns_write etc., aren't in any way hooked up to the guts of
> the ADP code so it would require a some work to make response caching
> work. Something for the future.
>
> My questions are:
>
> - does it make sense to do this extra step of turning the page into a
> proc at all?
> - does it make sense to overload the response caching config options for both?
>
> (and have I read the code right?)
>
> I guess my concern is that it's not obvious what's going on, both in
> terms of configuration and code implementation, and that it's going to
> hurt in the future when we want to add response caching to more parts
> of the code.
>
> I'm also wondering why two different strategies are being used for ADP
> and Tcl pages which are essentially identical. The script blocks for
> an ADP are cached per-interp which allows the byte-code to persist.
> The Tcl pages are turned into procs (but only optionally).
>
> ADP pages have a new 'singlescript' option which combines the text and
> script blocks into a single script block. The intent was to allow code
> to span <% .. %> boundaries, and a side effect is that a single error
> aborts the whole page. But the interesting things is that now it's
> basically a single chunk of Tcl to execute, like a Tcl page. Yet
> they're handled differently...
>
> Also, the constructed procs aren't garbage collected (same problem as
> the old Tcl page code)...
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
|
|
From: Stephen D. <sd...@gm...> - 2007-06-29 19:48:00
|
There's some new ADP result caching functionality. How does this
affect Tcl pages which are now executed by the ADP engine?
nsd/adpparse.c: NsAdpParse():
/*
* Special case when we evalutating Tcl file, we just wrap it as
* Tcl proc and save in ADP block with cache enabled or
* just execute the Tcl code in case of cache disabled
*/
nsd/adpeval.c: AdpSource():
/*
* Turn off TCL mode after cached result, in caching mode
* we wrap Tcl file into proc 'adp:filename' and return
* as result only
* ns_adp_append {<% adp:filename %>}
*
* The output will be cached as result and every time we call
* that Tcl file, cached command will be executed as long as
* file is unchanged, if modified then the file will be reloaded,
* recompiled into same Tcl proc and cached
*/
So when you enable result caching for ADP pages:
ns_section "ns/server/server1/adp"
ns_param cache true
or, in an adp page:
ns_adp_ctl cache true
or:
ns_adp_include -cache 1200 myfile.adp
what you're saying is after evaluating the script blocks in the adp,
and then combining them with the text blocks, cache that result and
don't re-execute the script blocks until the cache expires.
But for Tcl pages something different is going on. The exact same
config file option enables caching but now it means take the contents
of the Tcl file, make it the body of a hidden proc, then execute it
every time the page is called. The output is not cached.
In some respects this is fine. The commands that Tcl pages use:
ns_return, ns_write etc., aren't in any way hooked up to the guts of
the ADP code so it would require a some work to make response caching
work. Something for the future.
My questions are:
- does it make sense to do this extra step of turning the page into a
proc at all?
- does it make sense to overload the response caching config options for both?
(and have I read the code right?)
I guess my concern is that it's not obvious what's going on, both in
terms of configuration and code implementation, and that it's going to
hurt in the future when we want to add response caching to more parts
of the code.
I'm also wondering why two different strategies are being used for ADP
and Tcl pages which are essentially identical. The script blocks for
an ADP are cached per-interp which allows the byte-code to persist.
The Tcl pages are turned into procs (but only optionally).
ADP pages have a new 'singlescript' option which combines the text and
script blocks into a single script block. The intent was to allow code
to span <% .. %> boundaries, and a side effect is that a single error
aborts the whole page. But the interesting things is that now it's
basically a single chunk of Tcl to execute, like a Tcl page. Yet
they're handled differently...
Also, the constructed procs aren't garbage collected (same problem as
the old Tcl page code)...
|
|
From: Stephen D. <sd...@gm...> - 2007-06-29 18:33:45
|
On 6/29/07, Mike <nee...@gm...> wrote: > On 6/29/07, Stephen Deasey <sd...@gm...> wrote: > > Anyway, the idea is that starpacks should be supported because Zoran > > needs it, the Tcl file system API is ugly, and our coverage is spotty > > (static files work, ADP doesn't), so I'm suggesting that we drop most > > of the VFS calls and provide a separate implementation of static file > > and ADP file serving. > > > > Does this sound OK? > > I do not fully understand your suggestion, but if it means what I > suspect it does, then I think this is a bad idea. Namely, if you are > suggesting ripping out the tcl VFS interface in favor of a hack that > will allow running NS out of a starpack, I think this would be a step > backwards. Well, what I'm suggesting is that the current situation is a bit of a hack and I'm proposing (what I think is) a better way to meet the goals. But just so I'm understanding where you're coming from, what is the purpose of using the Tcl VFS interface if not for running out of a starpack? (or other similar mechanisms). You seem to be saying that the Tcl VFS is good, but that starpacks are uninteresting, or am I getting this wrong? |
|
From: Mike <nee...@gm...> - 2007-06-29 17:59:49
|
On 6/29/07, Stephen Deasey <sd...@gm...> wrote: > Anyway, the idea is that starpacks should be supported because Zoran > needs it, the Tcl file system API is ugly, and our coverage is spotty > (static files work, ADP doesn't), so I'm suggesting that we drop most > of the VFS calls and provide a separate implementation of static file > and ADP file serving. > > Does this sound OK? I do not fully understand your suggestion, but if it means what I suspect it does, then I think this is a bad idea. Namely, if you are suggesting ripping out the tcl VFS interface in favor of a hack that will allow running NS out of a starpack, I think this would be a step backwards. The idea of having compile-time option to optimize fastpath is not unreasonable, but that should be the exception for the performance critical setup, not the general rule. |
|
From: Stephen D. <sd...@gm...> - 2007-06-29 17:32:52
|
I noticed that the newly back-ported adp stuff uses calls like open() and stat() instead of Tcl_OpenFileChannel() etc., and therefore wont work in a Starpack (right?) environment. The current situation is that we swapped all (most..) of the file system calls for Tcl equivalents. One of the problems Vlad found was that actually this does have an impact on performance, and so now there are some wrappers in nsd/fastpath.c: e.g. NsFastOpen() which uses open() or Tcl_OpenFileChannel(), depending on a compile-time option. One of the things that has been bugging me is that the Tcl API is incredibly ugly, requiring Tcl objects and reference counting instead of plain old strings. So I thought it would be a good idea to fill out the file system wrappers, move them to nsd/file.c, and use them throughout the core. But now I'm wondering if that's such a good idea. Looking closer, there would still have to be #ifdef checks when calling things like Ns_ConnSendChannel() vs. Ns_ConnSendFd() in fastpath.c. And is it even necessary? If you're serving pages out of a starpack, then by definition you're not after the ultimate in speed, right? So, as the page serving code is actually very pluggable, perhaps it would be acceptable to create a module, nsstarpack (or whatever) that does the equivalent of ns_register_fastpath and would be called at startup to override that default. Same with ADP pages. What else? - The module loading stuff in modload.c. This needs to stay. It's a little uglier than it needs to be, but no big deal. - The early startup code which reads the config file and the binder file. This needs to stay for now, but you could imagine how this wouldn't matter if we turned the server into a Tcl package (next version :-). The config file, for example, requires that it be read from disk (or starpack) early, we then drop root privs, and then we create a slave interp with the ns_section and ns_param commands installed, then eval the file. It's basically all Tcl anyway, except now we do it from C. - pid file and logging. The pid stuff has been converted to Tcl VFS calls, but the logging, both error log and access log haven't. I think pid is basically the same as logging and could be the same. It's not a big deal either way, but for consistency, we could convert the pid stuff back to standard OS calls. Interestingly, the stuff in nsd/rollfile.c has been converted to Tcl VFS calls and it's kind of insane, in the sense that the log files themselves can't exist in a starpack but this code jumps through hoops to handle it. rollfile.c needs to be written in Tcl. Nice little project for someone. - Couple of loose ends: nsd/urlopen.c and nsd/tclimg.c. Not sure... Anyway, the idea is that starpacks should be supported because Zoran needs it, the Tcl file system API is ugly, and our coverage is spotty (static files work, ADP doesn't), so I'm suggesting that we drop most of the VFS calls and provide a separate implementation of static file and ADP file serving. Does this sound OK? |
14 messages has been excluded from this view by a project administrator.
