[hunchentoot-devel] suggested imporvement: setting content-type with keywords

[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 at 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 at 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 at 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 at 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 at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>