Good point. Sounds good to me. On Thu, Feb 19, 2009 at 4:00 PM, Mark Nottingham <mnot@yahoo-inc.com> wrote: > > The problem is that this will make it impossible to use an existing HTTP > header parser (e.g., in Python, Perl, Ruby, whatever's standard library), a > goal that's guided a lot of the design. > > Why not just use > > Link: </foo>; rel="something" > Comment: This one is for you, Joe! > Link </bar>; rel="joes-link" > > ? > > > > On 19/02/2009, at 3:54 AM, Dirk Balfanz wrote: > > >> >> On Wed, Feb 18, 2009 at 8:23 AM, Breno de Medeiros <breno@google.com> >> wrote: >> While /host-meta is intended to be parsed by machines and not >> human-readable content, it is often the case that users eyeball such content >> for clues. For instance: >> >> 1. Developer is writing and debugging a library to parse host-meta files. >> 2. Developer is looking at /host-meta examples to get clues on how to >> write one for his site. >> >> Being able to add human-readable comments on site-meta can be useful for >> such tasks. It also helps to preserve 'institutional memory' by >> documentation in place, which is often the only one that developers can >> locate. >> >> Should there be a simple mechanism for line comments in site-meta? >> >> +1 for comments. >> >> I propose that any line that starts with # (possibly preceded by >> whitespace) is a comment. >> >> Dirk. >> > > > -- > Mark Nottingham mnot@yahoo-inc.com > > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)
Received on Friday, 20 February 2009 02:38:59 UTC