- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 30 Mar 2007 12:02:36 +0200
- To: Espen Antonsen - 24SevenOffice <ea@24SevenOffice.com>
- CC: "w3c-lists@mikeschinkel.com" <w3c-lists@mikeschinkel.com>, "public-html@w3.org" <public-html@w3.org>
Espen Antonsen - 24SevenOffice schrieb: > sending again due to formatting problem in previous mail. Sorry. > >>*Why* do you think the scripts could not be cached? >>Furthermore: if the server is capable to produce a multipart/related >>response with in-lined scripts, why can't it in-line the scripts into >>the HTML body in the first place? >>Julian > > I see your point. Images is probably a better example than javascript > files. Only advantages having javascript in the multipart response is to > have one javascript file to maintain on the server instead of having > inline script in each html file. In *some* cases returning a multipart Maintenance is a separate issue. You can have a single source file, and let the server in-line it automatically. > response to the client with javascript could be a better solution than > having 10 external references to javascript files. When it comes to > caching I do not see how a javascript in a multipart response can be > cached and reused by another page. Off course that is when external > referenced javascript should be used. > >>Why can't you just include the Javascript inline like is already possible? >> Mike Schinkel > > Good question. Only reason would be easier code management on the > server, one file which can either be used as a external reference in a > script tag or included by the server in the multipart response. But like > I said above, dynamic images is a much better example of good use of > multipart response. So where's the advantage with images? In multipart/related, you force the client to refetch them although it may already have them. Best regards, Julian
Received on Friday, 30 March 2007 10:02:54 UTC