Re: [FileAPI] BlobBuilder.append(native)
On Thu, Sep 22, 2011 at 4:47 PM, Glenn Maynard gl...@zewt.org wrote: native Newlines must be transformed to the default line-ending representation of the underlying host filesystem. For example, if the underlying filesystem is FAT32, newlines would be transformed into \r\n pairs as the text was appended to the state of the BlobBuilder. This is a bit odd: most programs write newlines according to the convention of the host system, not based on peeking at the underlying filesystem. You won't even know the filesystem if you're writing to a network drive. I'd suggest must be transformed according to the conventions of the local system, and let implementations decide what that is. It should probably be explicit that the only valid options are \r\n and \n, or reading files back in which were transformed in this way will be difficult. Good catch--I'll fix that. Also, in the Issue above that, it seems to mean native where it says transparent. Yup. That too. Thanks!
Re: [FileAPI] BlobBuilder.append(native)
On Fri, 23 Sep 2011 01:47:15 +0200, Glenn Maynard gl...@zewt.org wrote: native Newlines must be transformed to the default line-ending representation of the underlying host filesystem. For example, if the underlying filesystem is FAT32, newlines would be transformed into \r\n pairs as the text was appended to the state of the BlobBuilder. This is a bit odd: most programs write newlines according to the convention of the host system, not based on peeking at the underlying filesystem. You won't even know the filesystem if you're writing to a network drive. I'd suggest must be transformed according to the conventions of the local system, and let implementations decide what that is. It should probably be explicit that the only valid options are \r\n and \n, or reading files back in which were transformed in this way will be difficult. Also, in the Issue above that, it seems to mean native where it says transparent. Can we get away with always using \n? -- Simon Pieters Opera Software
Re: [FileAPI] BlobBuilder.append(native)
On Fri, Sep 23, 2011 at 4:36 AM, Simon Pieters sim...@opera.com wrote: Can we get away with always using \n? Not if you want to be interoperable with native applications. You can't even open a text file in Notepad with Unix line endings. (Another reason underlying host filesystem doesn't make sense: this is BlobBuilder, not FileWriter--it's not associated with a file, so it's not associated with any particular filesystem.) By the way--I don't think it's worth starting a separate thread for this--This note is normative seems like a contradiction in terms. -- Glenn Maynard
Re: [FileAPI] BlobBuilder.append(native)
On Thu, Sep 22, 2011 at 7:47 PM, Glenn Maynard gl...@zewt.org wrote: native Newlines must be transformed to the default line-ending representation of the underlying host filesystem. For example, if the underlying filesystem is FAT32, newlines would be transformed into \r\n pairs as the text was appended to the state of the BlobBuilder. This is a bit odd: most programs write newlines according to the convention of the host system, not based on peeking at the underlying filesystem. You won't even know the filesystem if you're writing to a network drive. I'd suggest must be transformed according to the conventions of the local system, and let implementations decide what that is. It should probably be explicit that the only valid options are \r\n and \n, or reading files back in which were transformed in this way will be difficult. Agreed. Also, in the Issue above that, it seems to mean native where it says transparent. -- Glenn Maynard -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls
