From owner-freebsd-cvsweb@FreeBSD.ORG Mon Jan 5 12:14:23 2004 Return-Path: Delivered-To: freebsd-cvsweb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DC4116A4CE for ; Mon, 5 Jan 2004 12:14:23 -0800 (PST) Received: from smtp1.pp.htv.fi (smtp1.pp.htv.fi [212.90.64.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id A117143D2F for ; Mon, 5 Jan 2004 12:14:21 -0800 (PST) (envelope-from scop@FreeBSD.org) Received: from posti.pp.htv.fi (posti.pp.htv.fi [212.90.64.50]) by smtp1.pp.htv.fi (Postfix) with ESMTP id 5D1BF7FCED for ; Mon, 5 Jan 2004 22:14:20 +0200 (EET) Received: from [62.78.131.215] (cs78131215.pp.htv.fi [62.78.131.215]) /8.11.1) with ESMTP id i05KEJT19212 for ; Mon, 5 Jan 2004 22:14:19 +0200 (EET) From: Ville =?ISO-8859-1?Q?Skytt=E4?= To: freebsd-cvsweb@FreeBSD.org In-Reply-To: <3FF8DD46.5090501@obviously.com> References: <3FB23C1F.6040502@obviously.com> <3FB28082.6070707@obviously.com><3FBCEA3F.4050106@obviously.com> <3FD3547A.5010400@obviously.com><3FDF6F74.4070307@obviously.com> <3FEB7626.2030606@obviously.com><3FEF5E93.8020600@obviously.com> <3FF8DD46.5090501@obviously.com> Content-Type: text/plain Organization: FreeBSD Message-Id: <1073333659.9121.229.camel@bobcat.mine.nu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 05 Jan 2004 22:14:19 +0200 Content-Transfer-Encoding: 7bit Subject: MIME types, links, diff tools (was: Re: Patch to cvsweb?) X-BeenThere: freebsd-cvsweb@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS Web maintenance mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2004 20:14:23 -0000 On Mon, 2004-01-05 at 05:43, Bryce Nesbitt (mailing list account) wrote: > I agree that using CVS's "b" (binary) flag is a good hint. > > But why hard code the response? Hm... I may have been unclear (or I may be missing something), but I was not thinking about hardcoding anything in particular. Except kind of that for files we know (somehow, possibly using the "b" flag) are binary, I think it would make sense _not_ to show any "as text", HTMLified source, regular diff or annotate links since the output would be a mess anyway. > For each combination of binary flag and > mime type, I might want select allowable diff and download types > independently: > > Diff as: > text > colored > side-by-side I would not show those difftypes for binary files (again, assuming we have some robust/consistent way of determining exactly what is a "binary file"). > shape_diff.exe (external) > exell_diff.exe (external) These, on the other hand, would be shown for all files that have these dedicated diff tools set (probably based on the MIME type), no matter if binary or not. > Download as: > Native mime type (e.g. "application/msword") > As text Again, I would skip the "as text" link if we know the file will most likely not be viewable as text anyway. Of course, as a safety measure against detection bugs, there could be a "sticky" option somewhere for users to choose whether they'd want to see the "intelligent, detected" set of diff/download/view options, or all of them. And probably default that to the "intelligent" set. Diffing archive contents adds another level of complexity, whether to use plain "diff -r" or dedicated tools for diffing each file in the arcive separately, and how to sanely combine the results of different diff tools if the latter way is chosen. Thoughts?