Re: [FileAPI] BlobBuilder.append("native")

[Eric U]

On Thu, Sep 22, 2011 at 4:47 PM, Glenn Maynard  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")

[Jarred Nicholls]

On Thu, Sep 22, 2011 at 7:47 PM, Glenn Maynard  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

Re: [FileAPI] BlobBuilder.append("native")

[Glenn Maynard]

On Fri, Sep 23, 2011 at 4:36 AM, Simon Pieters  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")

[Simon Pieters]

On Fri, 23 Sep 2011 01:47:15 +0200, Glenn Maynard  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

[FileAPI] BlobBuilder.append("native")

[Glenn Maynard]

> "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".

-- 
Glenn Maynard