From russ at acceleration.net Thu May 6 13:58:10 2010 From: russ at acceleration.net (Russ Tyndall) Date: Thu, 06 May 2010 09:58:10 -0400 Subject: [Bese-devel] Yaclml sxml comments Message-ID: <4BE2CAF2.7090402@acceleration.net> I have comments that need to get from tal through yaclml and out to the output stream, but currently the xmls parser doesnt save the value of the comment, and so all comments are dropped on parsing. I can do , but that seems a touch silly and error prone. I have attached a patch that will allow comments to appear as strings in the xmls representation, which (for me) allows comments to go from tal unmolested to the output stream (when *strip-comments* is nil). This bug was also mentioned in the following blog post: http://www.3ofcoins.net/2010/01/21/yaclml-in-pictures-part-ii-templating/ Hope this is useful for others, Russ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: comment-patch.diff URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: comment-patch.darcs URL: From burban at opopop.net Mon May 10 21:51:17 2010 From: burban at opopop.net (burban at opopop.net) Date: 10 May 2010 21:51:17 +0000 Subject: [Bese-devel] bug in ucw-core demo Message-ID: <871vdjjui2.fsf@default.opopop.net> Hi! I upgraded to the latest ucw-core from the darcs repo at http://common-lisp.net/project/ucw/repos/ucw-core/ It happens that the link "Test CALL/ANSWER MAGIC" in the demo doesn't work as expected: it's badly formatted when you hit "Test CALL", and it raises an error when you click "IT! (hit here)". I hunted that down to darcs patch tagged: Wed May 6 21:40:52 CEST 2009 clinton at unknownlamer.org * Move proper defintion of `ucw-core:make-action' into ucw-core Ignore-this: abbb3a9c4d7ff9a6addf4f3b5c3cbcff * Use ucw-standard definition and move *default-action-class* into ucw-core with a new default of 'basic-action * Rebind ucw-core:*default-action-class* to 'ucw-standard:standard-action in an :around method on `standard-application's `service' * Export *default-action-class* and `action' from ucw-core packagec The crux is basic-action is not enough to get that demo working, the workaround is easy: hunk ./demo/demo.lisp 19 -(defclass demo-application (basic-application) +(defclass demo-application (standard-application) Regards. -- B. Urban From anton.rizov at gmail.com Tue May 11 14:27:30 2010 From: anton.rizov at gmail.com (Anton Rizov) Date: Tue, 11 May 2010 10:27:30 -0400 Subject: [Bese-devel] How can I help Message-ID: Hi guys, I've been researching ucw for a few days and I definitely want to learn more. The best way in my experience is to start working on some trivial improvements either in code or documentation. How can I help? Kind regards, Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: From burban at opopop.net Tue May 11 22:16:31 2010 From: burban at opopop.net (burban at opopop.net) Date: 11 May 2010 22:16:31 +0000 Subject: [Bese-devel] How can I help In-Reply-To: References: Message-ID: <87d3x2uls0.fsf@default.opopop.net> Anton Rizov writes: > Hi guys, > > I've been researching ucw for a few days and I definitely want to learn The official project site is there: http://common-lisp.net/project/ucw > more. The best way in my experience is to start working on some > trivial improvements either in code or documentation. > > How can I help? > I learned UCW by writing a web site with it: http://lisp.opopop.net You will find the full code of the site there, as an example (even if it is not stellar "UCW style" code). There are several quite decent beginners tutorials about UCW. But documenting with real life examples the advanced aspects of UCW is lacking. For the code, I see work to be done in cleaning up the core even more (there are a lot of unused files in ucw-core currently), improving its extensibility and actually providing some useful extensions. Regards. -- B. Urban From anton.rizov at gmail.com Wed May 12 14:48:07 2010 From: anton.rizov at gmail.com (Anton Rizov) Date: Wed, 12 May 2010 10:48:07 -0400 Subject: [Bese-devel] How can I help In-Reply-To: <87d3x2uls0.fsf@default.opopop.net> References: <87d3x2uls0.fsf@default.opopop.net> Message-ID: On Tue, May 11, 2010 at 6:16 PM, wrote: > Anton Rizov writes: > > > Hi guys, > > > > I've been researching ucw for a few days and I definitely want to learn > > The official project site is there: http://common-lisp.net/project/ucw > > > more. The best way in my experience is to start working on some > > trivial improvements either in code or documentation. > > > > How can I help? > > > > I learned UCW by writing a web site with it: http://lisp.opopop.net > You will find the full code of the site there, as an example (even if > it is not stellar "UCW style" code). > > Actually I have already downloaded both lisp-app and paragent and read the sources. They were quite useful and I can only thank you for providing them. > There are several quite decent beginners tutorials about UCW. But > documenting with real life examples the advanced aspects of UCW is > lacking. > I can't claim I understand these advanced aspects but I can try to build and document such a sample application. Can we build a list of things to be demonstrated? Any ideas what it (the application) should do? For the code, I see work to be done in cleaning up the core even more > (there are a lot of unused files in ucw-core currently), improving its > extensibility and actually providing some useful extensions. > > Indeed I noticed there are unused files. I'll try to do a clean up. Also I was a little confused that there are two different implementations of user-login component. It looks like one of them is only used in adim app and the other one is actually exported for clients to use. Regards. > > -- > > B. Urban > > _______________________________________________ > bese-devel mailing list > bese-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From burban at opopop.net Wed May 12 22:23:30 2010 From: burban at opopop.net (burban at opopop.net) Date: 12 May 2010 22:23:30 +0000 Subject: [Bese-devel] How can I help In-Reply-To: References: <87d3x2uls0.fsf@default.opopop.net> Message-ID: <87sk5wrc7x.fsf@default.opopop.net> Anton Rizov writes: [...] > > There are several quite decent beginners tutorials about UCW. But > > documenting with real life examples the advanced aspects of UCW is > > lacking. > > > > I can't claim I understand these advanced aspects but I can try to build and > document such a sample application. Can we build a list of things to be > demonstrated? Any ideas what it (the application) should do? You can see the advanced aspects at work in the ucw_ajax demos, which I run at http://ucw.opopop.net. A useful task would be to try to explain them more thoroughly and in the process backport them to ucw-core, with a more "real-life" feel. (A warning though about some of the demos: they are based on an old version of Dojo, which doesn't work exactly the same with the latest browsers. Your best bet is Iceweasel in Debian Etch.) If you take that path, notice that I have backported to ucw-core basic ajax functionality, but with jquery. (Here also, I noticed recently that depending on browser, my code may not work! A correction is in the pipeline.) > For the code, I see work to be done in cleaning up the core even more > > (there are a lot of unused files in ucw-core currently), improving its > > extensibility and actually providing some useful extensions. > > > > Indeed I noticed there are unused files. I'll try to do a clean up. > > Also I was a little confused that there are two different implementations > of user-login component. It looks like one of them is only used in adim app > and the other one is actually exported for clients to use. There are certainly other cases of not completely rational ucw code you are welcome to hunt down. Regards. -- B. Urban From clinton at unknownlamer.org Fri May 14 03:42:28 2010 From: clinton at unknownlamer.org (Clinton Ebadi) Date: Thu, 13 May 2010 23:42:28 -0400 Subject: [Bese-devel] bug in ucw-core demo In-Reply-To: <871vdjjui2.fsf@default.opopop.net> (burban@opopop.net's message of "10 May 2010 21:51:17 +0000") References: <871vdjjui2.fsf@default.opopop.net> Message-ID: <87aas3no7v.fsf@rvannith.home.unknownlamer.org> burban at opopop.net writes: > Hi! > > I upgraded to the latest ucw-core from the darcs repo at > http://common-lisp.net/project/ucw/repos/ucw-core/ > > It happens that the link "Test CALL/ANSWER MAGIC" in the demo doesn't > work as expected: it's badly formatted when you hit "Test CALL", > and it raises an error when you click "IT! (hit here)". I hunted > that down to darcs patch tagged: > > Wed May 6 21:40:52 CEST 2009 clinton at unknownlamer.org > * Move proper defintion of `ucw-core:make-action' into ucw-core > Ignore-this: abbb3a9c4d7ff9a6addf4f3b5c3cbcff > * Use ucw-standard definition and move *default-action-class* into > ucw-core with a new default of 'basic-action > * Rebind ucw-core:*default-action-class* to > 'ucw-standard:standard-action in an :around method on > `standard-application's `service' > * Export *default-action-class* and `action' from ucw-core packagec > > The crux is basic-action is not enough to get that demo working, > the workaround is easy: > hunk ./demo/demo.lisp 19 > -(defclass demo-application (basic-application) > +(defclass demo-application (standard-application) Thanks for catching that. I applied the fix to http://darcs.unknownlamer.org/ucw-core_clinton. In the next weekish I'm going to finally do the magic gpg key exchange to give me commit access to the ucw repo and push all of my stable patches there. -- Ruled by the ebb of my oceans Slaves to the dusk and the dawn Your petri dish civilisations Are buried and born -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 229 bytes Desc: not available URL: From anton.rizov at gmail.com Fri May 14 16:42:15 2010 From: anton.rizov at gmail.com (Anton Rizov) Date: Fri, 14 May 2010 12:42:15 -0400 Subject: [Bese-devel] Some trivial changes Message-ID: Hi, Before anything else I have a "management" question. As I'll be doing (mostly trivial for now) changes so it would be useful to know about the policy here. What do you prefer to ask/discuss on this list before changing anything or directly send patches? This time I'll ask: * Is there any reason in-application is not exported? In protocol.lisp there is a macro in-application but it is not exported. IMHO it could be useful in client code as it will eliminate the need to specify :application argument in defentry-point. Any objections about exporting it? * Is *ucw-applications-directory* in vars.lisp needed? I don't think this variable is actually used. Any reason to keep it? * Is *ucw-systems* in vars.lisp needed? Same as *ucw-applications-directory* * How about changing default value fo create-server :application argument? - (applications *ucw-applications*) + (applications (or *ucw-applications* '(*default-application*)) So than one could write: (in-application (make-instance 'demo-application)) (create-server) rather than (create-server :applications '(*default-application*)) Or maybe changing in-application (pushnew *default-application* *ucw-applications*) Kind regards, Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: From burban at opopop.net Sun May 16 22:28:55 2010 From: burban at opopop.net (burban at opopop.net) Date: 16 May 2010 22:28:55 +0000 Subject: [Bese-devel] Some trivial changes In-Reply-To: References: Message-ID: <878w7ja3bs.fsf@default.opopop.net> Anton Rizov writes: > Hi, > > Before anything else I have a "management" question. As I'll be doing > (mostly trivial for now) changes so it would be useful to know about the > policy here. What do you prefer to ask/discuss on this list before > changing anything or directly send patches? > > This time I'll ask: > > * Is there any reason in-application is not exported? > > In protocol.lisp there is a macro in-application but it is not > exported. IMHO it could be useful in client code as it will > eliminate the need to specify :application argument in > defentry-point. > > Any objections about exporting it? > > * Is *ucw-applications-directory* in vars.lisp needed? > > I don't think this variable is actually used. Any reason to keep it? > > * Is *ucw-systems* in vars.lisp needed? > > Same as *ucw-applications-directory* IMHO, in-application, *ucw-applications-directory* and *ucw-systems* are not used elsewhere, so could be suppressed. *ucw-applications* is used in create-server, so should be kept to not break existing code. > * How about changing default value fo create-server :application argument? > > - (applications *ucw-applications*) > + (applications (or *ucw-applications* '(*default-application*)) What if *default-application* stays nil? > So than one could write: > > (in-application (make-instance 'demo-application)) > > (create-server) > > rather than > > (create-server :applications '(*default-application*)) I prefer the later, as it clearly shows what applications are handled by what server. > Or maybe changing in-application > (pushnew *default-application* *ucw-applications*) Another concern I have with 1 line defmacro such as in-application is that in most cases they don't bring clarity and simplification to the code; at the contrary, in-application hides that there is a side effect. Sincerely. -- B. Urban From drewc at tech.coop Mon May 17 05:36:25 2010 From: drewc at tech.coop (Drew Crampsie) Date: Sun, 16 May 2010 22:36:25 -0700 Subject: [Bese-devel] Some trivial changes In-Reply-To: References: Message-ID: Hi Anton, I like most of your ideas, but this one is no good : On 14 May 2010 09:42, Anton Rizov wrote: > > * How about changing default value fo create-server :application argument? > > - (applications *ucw-applications*) > + (applications (or *ucw-applications* '(*default-application*)) I'm pretty sure that UCW applications are not symbols... lot of methods to write if you want that to work! :P Cheers, drewc PS: i suppose, with some EQL specializers, and maybe using the symbol-plist... it could work pretty well. From anton.rizov at gmail.com Mon May 17 19:27:52 2010 From: anton.rizov at gmail.com (Anton Rizov) Date: Mon, 17 May 2010 15:27:52 -0400 Subject: [Bese-devel] Some trivial changes In-Reply-To: <878w7ja3bs.fsf@default.opopop.net> References: <878w7ja3bs.fsf@default.opopop.net> Message-ID: On Sun, May 16, 2010 at 6:28 PM, wrote: > Anton Rizov writes: > > > Hi, > > > > Before anything else I have a "management" question. As I'll be doing > > (mostly trivial for now) changes so it would be useful to know about the > > policy here. What do you prefer to ask/discuss on this list before > > changing anything or directly send patches? > > > > This time I'll ask: > > > > * Is there any reason in-application is not exported? > > > > In protocol.lisp there is a macro in-application but it is not > > exported. IMHO it could be useful in client code as it will > > eliminate the need to specify :application argument in > > defentry-point. > > > > Any objections about exporting it? > > > > * Is *ucw-applications-directory* in vars.lisp needed? > > > > I don't think this variable is actually used. Any reason to keep it? > > > > * Is *ucw-systems* in vars.lisp needed? > > > > Same as *ucw-applications-directory* > > IMHO, in-application, *ucw-applications-directory* and *ucw-systems* > are not used elsewhere, so could be suppressed. *ucw-applications* is > used in create-server, so should be kept to not break existing code. > OK. Won't touch *ucw-applications*. > > > * How about changing default value fo create-server :application > argument? > > > > - (applications *ucw-applications*) > > + (applications (or *ucw-applications* '(*default-application*)) > > What if *default-application* stays nil? > > > > So than one could write: > > > > (in-application (make-instance 'demo-application)) > > > > (create-server) > > > > rather than > > > > (create-server :applications '(*default-application*)) > > I prefer the later, as it clearly shows what applications are handled > by what server. > > > Or maybe changing in-application > > (pushnew *default-application* *ucw-applications*) > > Another concern I have with 1 line defmacro such as in-application is > that in most cases they don't bring clarity and simplification to the > code; at the contrary, in-application hides that there is a side effect. > > I guess you're right. It may be a personal preference but it looks more clear to me to write (in-application some-application) than (setf *default-application* some-application). In addition I assosiate it with in-package macro. So what's the verdict: Export or Remove? Sincerely. > > -- > > B. Urban > Kind regards, Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: remove-unused-variables.diff Type: application/octet-stream Size: 274 bytes Desc: not available URL: From drewc at tech.coop Mon May 17 20:00:45 2010 From: drewc at tech.coop (Drew Crampsie) Date: Mon, 17 May 2010 13:00:45 -0700 Subject: [Bese-devel] Some trivial changes In-Reply-To: References: <878w7ja3bs.fsf@default.opopop.net> Message-ID: On 17 May 2010 12:27, Anton Rizov wrote: >> >> > ? So than one could write: >> > >> > ? (in-application (make-instance 'demo-application)) What happens when you re-evaluate this form? Cheers, drewc >> > >> > ? (create-server) >> > >> > ? rather than >> > >> > ? (create-server :applications '(*default-application*)) >> >> I prefer the later, as it clearly shows what applications are handled >> by what server. >> >> > ? Or maybe changing in-application >> > ? (pushnew *default-application* *ucw-applications*) >> >> Another concern I have with 1 line defmacro such as in-application is >> that in most cases they don't bring clarity and simplification to the >> code; at the contrary, in-application hides that there is a side effect. >> > I guess you're right. It may be a personal preference but it looks more > clear to me to > write (in-application some-application) than (setf *default-application* > some-application). > In addition I assosiate it with in-package macro. > > So what's the verdict: Export or Remove? > > >> Sincerely. >> >> -- >> >> B. Urban > > > Kind regards, > Anton > > > _______________________________________________ > bese-devel mailing list > bese-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel > > From anton.rizov at gmail.com Wed May 19 16:22:07 2010 From: anton.rizov at gmail.com (Anton Rizov) Date: Wed, 19 May 2010 12:22:07 -0400 Subject: [Bese-devel] Some trivial changes In-Reply-To: References: <878w7ja3bs.fsf@default.opopop.net> Message-ID: On Mon, May 17, 2010 at 4:00 PM, Drew Crampsie wrote: > On 17 May 2010 12:27, Anton Rizov wrote: > > >> > >> > So than one could write: > >> > > >> > (in-application (make-instance 'demo-application)) > > > What happens when you re-evaluate this form? > Absolutely nothing pleasant, or expected I must agree? But then I'm not sure I understand the purpose of *default-application* I can write something like: (defvar *my-application* (make-instance ....)) (setf *default-application* *my-application*) and then omit :application arg in defentry-point. Is this the recommended way? All examples I have seen (not many really) provide explicitly :application arg, so I guess the answer is no. Am I missing something? It's a small thing, I know, but I'm just curious. BTW I forgot to to delete *ucw-applications-directory* and *ucw-systems* from the ucw-core.asd, so here is an update. Regards, Anton > Cheers, > > drewc > > >> > > >> > (create-server) > >> > > >> > rather than > >> > > >> > (create-server :applications '(*default-application*)) > >> > >> I prefer the later, as it clearly shows what applications are handled > >> by what server. > >> > >> > Or maybe changing in-application > >> > (pushnew *default-application* *ucw-applications*) > >> > >> Another concern I have with 1 line defmacro such as in-application is > >> that in most cases they don't bring clarity and simplification to the > >> code; at the contrary, in-application hides that there is a side effect. > >> > > I guess you're right. It may be a personal preference but it looks more > > clear to me to > > write (in-application some-application) than (setf *default-application* > > some-application). > > In addition I assosiate it with in-package macro. > > > > So what's the verdict: Export or Remove? > > > > > >> Sincerely. > >> > >> -- > >> > >> B. Urban > > > > > > Kind regards, > > Anton > > > > > > _______________________________________________ > > bese-devel mailing list > > bese-devel at common-lisp.net > > http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: remove-unused-variables.diff Type: application/octet-stream Size: 389 bytes Desc: not available URL: From anton.rizov at gmail.com Sat May 22 17:13:47 2010 From: anton.rizov at gmail.com (Anton Rizov) Date: Sat, 22 May 2010 13:13:47 -0400 Subject: [Bese-devel] serve-file and content-disposition Message-ID: Hi, serve-file method doesn't expose content-disposition parameter. Is that intentional?. I was looking at how to serve static content with ucw and found serve-file. Unfortunately it assumes that content disposition is "attachment" and doesn't provide a way for one to specify an alternative. It was easy to change it, so that it could be used as: (serve-file (make-pathname ...) :content-disposition "inline" :content-type "text/html; charset=\"...\"") but I'm wondering whether there is a reason or it's only a matter of unintentional omission. Is "attachment" really the preferred way to serve static content, especially for html files? I tried using static-roots-application-mixin and was surprised to see download dialog opening. Regards, Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: From burban at opopop.net Wed May 26 23:41:51 2010 From: burban at opopop.net (burban at opopop.net) Date: 26 May 2010 23:41:51 +0000 Subject: [Bese-devel] serve-file and content-disposition In-Reply-To: References: Message-ID: <878w76dydc.fsf@default.opopop.net> Anton Rizov writes: > Hi, > > serve-file method doesn't expose content-disposition parameter. Is > that intentional?. > > I was looking at how to serve static content with ucw and found > serve-file. Unfortunately it assumes that content disposition is > "attachment" and doesn't provide a way for one to specify an > alternative. > > It was easy to change it, so that it could be used as: > > (serve-file (make-pathname ...) > :content-disposition "inline" > :content-type "text/html; charset=\"...\"") > > but I'm wondering whether there is a reason or it's only a matter of > unintentional omission. > > Is "attachment" really the preferred way to serve static content, > especially for html files? I tried using > static-roots-application-mixin and was surprised to see download > dialog opening. Well, can't really answer about your content-type question. But I never used static-roots-application-mixin before, relying on apache to direct the request to static file or UCW handling. You triggered my curiosity. So static-roots-application-mixin works (I tried downloading non-html files). Except that you have to run the :after method startup-application by hand; registering the application in a running server won't do it. You are normally not hit by that as other types of applications don't need an initializer. I see no reason that initialization step couldn't be put in make-instance, or am I missing something? Regards. -- B. Urban From clinton at unknownlamer.org Thu May 27 15:35:31 2010 From: clinton at unknownlamer.org (Clinton Ebadi) Date: Thu, 27 May 2010 11:35:31 -0400 Subject: [Bese-devel] serve-file and content-disposition In-Reply-To: <878w76dydc.fsf@default.opopop.net> (burban@opopop.net's message of "26 May 2010 23:41:51 +0000") References: <878w76dydc.fsf@default.opopop.net> Message-ID: <87k4qpmk70.fsf@rvannith.home.unknownlamer.org> burban at opopop.net writes: > Well, can't really answer about your content-type question. But I > never used static-roots-application-mixin before, relying on apache to > direct the request to static file or UCW handling. You triggered my > curiosity. > > So static-roots-application-mixin works (I tried downloading non-html > files). Except that you have to run the :after method > startup-application by hand; registering the application in a running > server won't do it. You are normally not hit by that as other types of > applications don't need an initializer. I see no reason that > initialization step couldn't be put in make-instance, or am I missing > something? IIRC You are not permitted to extend make-instance directly, and that would be the wrong time to register the entry points anyway (given that there may very well be no server associated with the application). AFAICT with the server protocol registering an application should *not* make it start anyway; there are separate `register-FOO' and `start-FOO' methods for a reason. I am thinking it should be an error to register an application with a server that is already running, but I'll defer to drewc's opinion on this. -- Jessie: but today i was a nerd Jessie: i even read slashdot. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 229 bytes Desc: not available URL: From clinton at unknownlamer.org Thu May 27 15:45:32 2010 From: clinton at unknownlamer.org (Clinton Ebadi) Date: Thu, 27 May 2010 11:45:32 -0400 Subject: [Bese-devel] serve-file and content-disposition In-Reply-To: (Anton Rizov's message of "Sat, 22 May 2010 13:13:47 -0400") References: Message-ID: <87d3whmjqb.fsf@rvannith.home.unknownlamer.org> Anton Rizov writes: > Hi, > > serve-file method doesn't expose content-disposition parameter. Is > that intentional?. > > I was looking at how to serve static content with ucw and found > serve-file.? Unfortunately it assumes that content disposition is > "attachment" and doesn't provide a way for one to specify an > alternative. > > It was easy to change it, so that it could be used as: > > (serve-file (make-pathname ...) > ? ??? ????? :content-disposition "inline" > ? ??? ????? :content-type "text/html; charset=\"...\"") > > but I'm wondering whether there is a reason or it's only a matter of > unintentional omission. > > Is "attachment" really the preferred way to serve static content, > especially for html files? I tried using > static-roots-application-mixin and was surprised to see download > dialog opening. The file serving parts of UCW have received little love. They /work/, but not much more... Regarded content disposition, I am unsure that anything other than attachment makes sense. See 19.5.1 of [0]: content-disposition = "Content-Disposition" ":" disposition-type *( ";" disposition-parm ) disposition-type = "attachment" | disp-extension-token disposition-parm = filename-parm | disp-extension-parm filename-parm = "filename" "=" quoted-string disp-extension-token = token disp-extension-parm = token "=" ( token | quoted-string ) AFAICT from this attachment is the only standard content disposition for HTTP 1.1, and anything else is an extension. According to [1] it is not even a standard part of HTTP and has security issues, and so I am now leaning toward just not setting it at all. Does anyone else have an opinon? If not I will go ahead with removing content disposition entirely. [0] http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.5.1 [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.5 -- Ethan: i'm working on myself Ethan: the self is the most important thing Ethan: i learned this from a packet of tea -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 229 bytes Desc: not available URL: From attila.lendvai at gmail.com Thu May 27 16:36:47 2010 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Thu, 27 May 2010 18:36:47 +0200 Subject: [Bese-devel] serve-file and content-disposition In-Reply-To: <87d3whmjqb.fsf@rvannith.home.unknownlamer.org> References: <87d3whmjqb.fsf@rvannith.home.unknownlamer.org> Message-ID: > Does anyone else have an opinon? If not I will go ahead with removing > content disposition entirely. content-disposition: attachment is important e.g. if you want to prevent the annoying pdf plugin to embed a pdf in the browser, or you want to make sure a txt file is saved instead of displayed. we have it _slightly_ better in wui: http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.wui;a=headblob;f=/source/server/server.lisp but without further requirements we didn't make it as shiny as possible. -- attila From burban at opopop.net Thu May 27 21:07:01 2010 From: burban at opopop.net (burban at opopop.net) Date: 27 May 2010 21:07:01 +0000 Subject: [Bese-devel] serve-file and content-disposition In-Reply-To: <87k4qpmk70.fsf@rvannith.home.unknownlamer.org> References: <878w76dydc.fsf@default.opopop.net> <87k4qpmk70.fsf@rvannith.home.unknownlamer.org> Message-ID: <87bpc1qcju.fsf@default.opopop.net> Clinton Ebadi writes: > burban at opopop.net writes: > > > Well, can't really answer about your content-type question. But I > > never used static-roots-application-mixin before, relying on apache to > > direct the request to static file or UCW handling. You triggered my > > curiosity. > > > > So static-roots-application-mixin works (I tried downloading non-html > > files). Except that you have to run the :after method > > startup-application by hand; registering the application in a running > > server won't do it. You are normally not hit by that as other types of > > applications don't need an initializer. I see no reason that > > initialization step couldn't be put in make-instance, or am I missing > > something? > > IIRC You are not permitted to extend make-instance directly, and that OOPS, I was meaning an :after initialize-instance. This works: (in-package :ucw-standard) (defmethod initialize-instance :after ((app static-roots-application-mixin) &rest initargs &key &allow-other-keys) (when-bind static-roots (application.static-roots app) (mapc (lambda (root) (defentry-point (car root) (:application app :class starts-with-dispatcher :with-call/cc nil :action-options (:class 'action)) () (serve-file (merge-pathnames *dispatcher-url-suffix* (cdr root))))) static-roots))) It's not so different from what defcomponent macro is doing. > would be the wrong time to register the entry points anyway (given that > there may very well be no server associated with the application). defentry-point doesn't need the :application argument to be registered to a server to work, if its body doesn't refer to that server. > AFAICT with the server protocol registering an application should *not* > make it start anyway; there are separate `register-FOO' and `start-FOO' > methods for a reason. I am thinking it should be an error to register an > application with a server that is already running, but I'll defer to > drewc's opinion on this. I register applications with a server that is already running (starting with no registered apps), without harm so far... >From the code, startup-application and shutdown-application bother with session clearing, so you are right. In practice, only shutdown-application does real work, which explain I am currently fine. Good point to keep in mind though... Regards. -- B. Urban From daniel at whitehouse.id.au Thu May 27 23:31:49 2010 From: daniel at whitehouse.id.au (Daniel White) Date: Fri, 28 May 2010 09:31:49 +1000 Subject: [Bese-devel] [PATCH] Use the provided form for session in WITH-LOCK-HELD-ON-SESSION In-Reply-To: <20090923112408.02e0f5c9@whitehouse.id.au> References: <20090923112408.02e0f5c9@whitehouse.id.au> Message-ID: On Wed, Sep 23, 2009 at 11:24 AM, Daniel White wrote: > Previously it was capturing the lexical value of session. I've noticed this hasn't been pushed into the ucw-core repository. Any problems with the patch and is the repository being updated and/or maintained? Cheers, -- Daniel White From clinton at unknownlamer.org Fri May 28 03:48:19 2010 From: clinton at unknownlamer.org (Clinton Ebadi) Date: Thu, 27 May 2010 23:48:19 -0400 Subject: [Bese-devel] [PATCH] Use the provided form for session in WITH-LOCK-HELD-ON-SESSION In-Reply-To: (Daniel White's message of "Fri, 28 May 2010 09:31:49 +1000") References: <20090923112408.02e0f5c9@whitehouse.id.au> Message-ID: <871vcwn0u4.fsf@rvannith.home.unknownlamer.org> Daniel White writes: > On Wed, Sep 23, 2009 at 11:24 AM, Daniel White wrote: >> Previously it was capturing the lexical value of session. > > I've noticed this hasn't been pushed into the ucw-core repository. > Any problems with the patch and is the repository being updated and/or > maintained? Could you resend the patch? I probably just missed it. > Cheers, -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 229 bytes Desc: not available URL: From daniel at whitehouse.id.au Fri May 28 04:05:35 2010 From: daniel at whitehouse.id.au (Daniel White) Date: Fri, 28 May 2010 14:05:35 +1000 Subject: [Bese-devel] [PATCH] Use the provided form for session in WITH-LOCK-HELD-ON-SESSION In-Reply-To: <871vcwn0u4.fsf@rvannith.home.unknownlamer.org> References: <20090923112408.02e0f5c9@whitehouse.id.au> <871vcwn0u4.fsf@rvannith.home.unknownlamer.org> Message-ID: On Fri, May 28, 2010 at 1:48 PM, Clinton Ebadi wrote: > Daniel White writes: > >> On Wed, Sep 23, 2009 at 11:24 AM, Daniel White wrote: >>> Previously it was capturing the lexical value of session. >> >> I've noticed this hasn't been pushed into the ucw-core repository. >> Any problems with the patch and is the repository being updated and/or >> maintained? > > Could you resend the patch? I probably just missed it. Drew actually pointed out that it doesn't appear in the archives. I actually resent it a few hours ago, but it hasn't appeared in the archives, either. I've also sent another separate patch today that doesn't seem to have arrived, either. Mildly frustrating that I've sent patches, but haven't ever received a bounce or failure message. -- Daniel White