I'm taking this back to the mailing list. I think there's no need to discuss this in private.
FWIW, I agree with Hans and don't think this is a very useful patch. You argue that with the patch you won't have to memorize mime types, but then you'll have to memorize file suffixes instead. And even if you don't need to learn them (as many of those suffixes have become second nature to us), they are a pretty arbitrary classification from the olden days of operating systems. Finally, how many different mime types will you use in a typical web application? Is it such a big deal?
Thanks, Edi.
On Wed, Apr 7, 2010 at 12:05 AM, Hans Hübner hans.huebner@gmail.com wrote:
Ala'a,
hereby I forward your reply to Edi. I think the basic concern is that MIME types are standardized, whereas keywords are not, and that it is not clear what keywords are supported and how keywords would be added. I agree with you that abstraction is good, but it is good only if it does not break easily, because, say, no new MIME types can be added, or there is ambiguity between MIME types and keywords as in the case of XML. Sometimes, something that first seemed simple and straightforward becomes cumbersome and ugly. This is not to say that your patch is in that class, I'm just saying that there may be valid counterarguments against including such a simple thing in the base HTTP surrogate because it does not scale beyond the simple use cases provoided as example.
That said, let's see if Edi has an opinion.
-Hans
---------- Forwarded message ---------- From: Ala'a (cmo-0) amalawi@gmail.com Date: Tue, Apr 6, 2010 at 19:16 Subject: Re: [hunchentoot-devel] suggested imporvement: setting content-type with keywords To: Hans Hübner hans.huebner@gmail.com
Hi Hans,
I understand, thus the followings are the motives/notes/thoughts regarding the patch:
- As a developer I do not want to be concerned/or memorize that
sending pdf should be using "application/pdf". The details of mime types should be hidden (a kind of abstraction) in other words, moving from constructing the details of the response (as much as possible), and concentrating on the task at hand which is developing the web content (js, ajax, html and other content dynamic and/or static). In general there is no productivity boost, except to avoid looking for the right mime type, Is it application/something? or text/something? Maybe its time for googling mime types again ;)
- There are some uses of keyword designators in the API (like in
*lisp-errors-log-level* and the use of :post :get and :both in define-esay-handler) which could be strings, so I thought/assumed that my patch will not be a stranger within the current API.
- Still the API is backward compatible, there is no need to force the
users to use the new designator. And the code uses the already built in database for mime types.
- This patch can propagate the API abstraction upward and be used by
other extension (maybe another patch) like: (defun set-content-spec (mime-type-designator &optional disposition-type filename) ...) where mime-type-designator: the same value as taken by (setf content-type*). filename: the name of sent content. disposition-type: is either :inline (open within the browser) or :attachment (open a save-as dialog). so I can say something like: (defun lpo-pdf () (let ((lpo (query-for-lpo ...))) ;lpo is short for: local purchase order (set-content-spec :pdf :attachment (format nil "~A.pdf" (serial lpo))) (generate-pdf-content)))
sheesh, this is almost triple the size of the patch ;)
Regards,
Ala'a (cmo-0)
What I forgot: The function MIME-TYPE is already exported. If you don't want to memorize mime types, you can simply use that function.
On Wed, Apr 7, 2010 at 8:08 AM, Edi Weitz edi@agharta.de wrote:
I'm taking this back to the mailing list. I think there's no need to discuss this in private.
FWIW, I agree with Hans and don't think this is a very useful patch. You argue that with the patch you won't have to memorize mime types, but then you'll have to memorize file suffixes instead. And even if you don't need to learn them (as many of those suffixes have become second nature to us), they are a pretty arbitrary classification from the olden days of operating systems. Finally, how many different mime types will you use in a typical web application? Is it such a big deal?
Thanks, Edi.
On Wed, Apr 7, 2010 at 12:05 AM, Hans Hübner hans.huebner@gmail.com wrote:
Ala'a,
hereby I forward your reply to Edi. I think the basic concern is that MIME types are standardized, whereas keywords are not, and that it is not clear what keywords are supported and how keywords would be added. I agree with you that abstraction is good, but it is good only if it does not break easily, because, say, no new MIME types can be added, or there is ambiguity between MIME types and keywords as in the case of XML. Sometimes, something that first seemed simple and straightforward becomes cumbersome and ugly. This is not to say that your patch is in that class, I'm just saying that there may be valid counterarguments against including such a simple thing in the base HTTP surrogate because it does not scale beyond the simple use cases provoided as example.
That said, let's see if Edi has an opinion.
-Hans
---------- Forwarded message ---------- From: Ala'a (cmo-0) amalawi@gmail.com Date: Tue, Apr 6, 2010 at 19:16 Subject: Re: [hunchentoot-devel] suggested imporvement: setting content-type with keywords To: Hans Hübner hans.huebner@gmail.com
Hi Hans,
I understand, thus the followings are the motives/notes/thoughts regarding the patch:
- As a developer I do not want to be concerned/or memorize that
sending pdf should be using "application/pdf". The details of mime types should be hidden (a kind of abstraction) in other words, moving from constructing the details of the response (as much as possible), and concentrating on the task at hand which is developing the web content (js, ajax, html and other content dynamic and/or static). In general there is no productivity boost, except to avoid looking for the right mime type, Is it application/something? or text/something? Maybe its time for googling mime types again ;)
- There are some uses of keyword designators in the API (like in
*lisp-errors-log-level* and the use of :post :get and :both in define-esay-handler) which could be strings, so I thought/assumed that my patch will not be a stranger within the current API.
- Still the API is backward compatible, there is no need to force the
users to use the new designator. And the code uses the already built in database for mime types.
- This patch can propagate the API abstraction upward and be used by
other extension (maybe another patch) like: (defun set-content-spec (mime-type-designator &optional disposition-type filename) ...) where mime-type-designator: the same value as taken by (setf content-type*). filename: the name of sent content. disposition-type: is either :inline (open within the browser) or :attachment (open a save-as dialog). so I can say something like: (defun lpo-pdf () (let ((lpo (query-for-lpo ...))) ;lpo is short for: local purchase order (set-content-spec :pdf :attachment (format nil "~A.pdf" (serial lpo))) (generate-pdf-content)))
sheesh, this is almost triple the size of the patch ;)
Regards,
Ala'a (cmo-0)
Hi Edi,
Its not a memorizing issue per se, rather its all points together (designators convenience).
I agree with Hans about the XML types (and others as well) where I'll need to search the web. The patch was designed with :pdf, :jpeg, :gif, :svg, :png in mind (the cases used regularly).
Before the patch I tried mime-type function. It needs a pathname designator, however, this will work:
(setf (content-type*) (mime-type ".pdf"))
The final word is yours ;)
Regards,
Ala'a (cmo-0)
On Wed, Apr 7, 2010 at 10:08 AM, Edi Weitz edi@agharta.de wrote:
I'm taking this back to the mailing list. I think there's no need to discuss this in private.
FWIW, I agree with Hans and don't think this is a very useful patch. You argue that with the patch you won't have to memorize mime types, but then you'll have to memorize file suffixes instead. And even if you don't need to learn them (as many of those suffixes have become second nature to us), they are a pretty arbitrary classification from the olden days of operating systems. Finally, how many different mime types will you use in a typical web application? Is it such a big deal?
Thanks, Edi.
On Wed, Apr 7, 2010 at 12:05 AM, Hans Hübner hans.huebner@gmail.com wrote:
Ala'a,
hereby I forward your reply to Edi. I think the basic concern is that MIME types are standardized, whereas keywords are not, and that it is not clear what keywords are supported and how keywords would be added. I agree with you that abstraction is good, but it is good only if it does not break easily, because, say, no new MIME types can be added, or there is ambiguity between MIME types and keywords as in the case of XML. Sometimes, something that first seemed simple and straightforward becomes cumbersome and ugly. This is not to say that your patch is in that class, I'm just saying that there may be valid counterarguments against including such a simple thing in the base HTTP surrogate because it does not scale beyond the simple use cases provoided as example.
That said, let's see if Edi has an opinion.
-Hans
---------- Forwarded message ---------- From: Ala'a (cmo-0) amalawi@gmail.com Date: Tue, Apr 6, 2010 at 19:16 Subject: Re: [hunchentoot-devel] suggested imporvement: setting content-type with keywords To: Hans Hübner hans.huebner@gmail.com
Hi Hans,
I understand, thus the followings are the motives/notes/thoughts regarding the patch:
- As a developer I do not want to be concerned/or memorize that
sending pdf should be using "application/pdf". The details of mime types should be hidden (a kind of abstraction) in other words, moving from constructing the details of the response (as much as possible), and concentrating on the task at hand which is developing the web content (js, ajax, html and other content dynamic and/or static). In general there is no productivity boost, except to avoid looking for the right mime type, Is it application/something? or text/something? Maybe its time for googling mime types again ;)
- There are some uses of keyword designators in the API (like in
*lisp-errors-log-level* and the use of :post :get and :both in define-esay-handler) which could be strings, so I thought/assumed that my patch will not be a stranger within the current API.
- Still the API is backward compatible, there is no need to force the
users to use the new designator. And the code uses the already built in database for mime types.
- This patch can propagate the API abstraction upward and be used by
other extension (maybe another patch) like: (defun set-content-spec (mime-type-designator &optional disposition-type filename) ...) where mime-type-designator: the same value as taken by (setf content-type*). filename: the name of sent content. disposition-type: is either :inline (open within the browser) or :attachment (open a save-as dialog). so I can say something like: (defun lpo-pdf () (let ((lpo (query-for-lpo ...))) ;lpo is short for: local purchase order (set-content-spec :pdf :attachment (format nil "~A.pdf" (serial lpo))) (generate-pdf-content)))
sheesh, this is almost triple the size of the patch ;)
Regards,
Ala'a (cmo-0)
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-
Ala'a (cmo-0) -
Edi Weitz