l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
December 2: Social gathering
Next Installfest:
TBD
Latest News:
Nov. 18: Club officer elections
Page last updated:
2002 Jul 03 19:59

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Question: mod_dav.1.0.3 + apache.1.3.26 and CR/LFissues w
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Question: mod_dav.1.0.3 + apache.1.3.26 and CR/LFissues w/ MacOS+MSWin



On Wed, 3 Jul 2002, ME wrote:

[...]

> > > OK. Fine. I am subscribing to a ietf/w3 working group on WebDAV. If the
> > > RFC for Dav can be modified to be explicit on content modification for
> > > text files over http, perhaps the clients will add this feature. :-)
> 
> One memebers response seconded by another:
> 
> "The problem you describe is not particularly a WebDAV problem. IMAP and
> FTP are subject to the same problems.  MIME also does not attempt to fix
> the problem."
> 
> (Problem being the conversion of CR/LF, LF, CR to the local OS linebreak
> string.)

In one sense, they are right. WebDAV works through HTTP which is supposed
to define a solution to this problem.  In another sense, if WebDAV is
right there in Apache handling the response on its own and it screws it
up, then it is very much a WebDAV problem.

There is a standard for how text files are supposed to look on the
wire.  From there, every server and client should be able to convert to or
from their favorite format.

> "...the real offenders are not WebDAV clients.  It's applications like
> NotePad that can't display reasonable file formats that are problematic."
> 
> So, they know about this as a complaint, but do not see it as their issue.
> They see this as a client editor problem.

This is a shortsighted and arrogant attitude.

> Do I agree? I am not sure yet.
> 
> It creates less headaches for the server admin if the burden is shifted to
> the user to use an editor that understand different conventions. It
> creates more headaches for the desktop support people. Which is worse?

Multiple newline conventions exist.  A single on-the-wire standard for
newlines exists. When this common format is used during file transfers,
life is straightforward.  Pushing the problem onto every application that
wants to deal with a text file (not JUST editors!!!) is LUDICROUS!!!

> Another's response included:
> "If you try the try again with Mac OS X's TextEdit application, you'll see
> that it handles CR, LF and CR/LF correctly."

That is really nice.

And totally irrelevant, because that represents a miniscule fraction of
the programs that you might want to use to deal with text files.

> And this brings me back to the original post where I stated "BBEdit" and
> the editor from MetroWerks Code Warrior can both handle file as text
> editor and properly display the content reguardless of the local OS's
> ideas on the matter with text files they create. I of course stated in the
> original post that these were undesireable.
> 
> So, unless I choose to look to help add a new feature to Goliath (checkbox
> to enable a text translation feature), Cadaver (a flag or arguement on
> startup) and beg MS to allow for client side alteration of files or
> Notepad, and/or ask Apple to alter SimpleText my two solutions include:

It is convenient that we don't have to change the behemoth's idea of
newline formats to be compatible with the standard on-the-wire format.

> 1) Tell my users they can use "BBEdit" an editor like the one from
> CodeWarrior that understand the different conventions. (I know wordpad
> will deal with this for display, but when the file is saved, there is risk
> for contaimination of text data with 8 bit binary data and sequences to
> enable/disable bold etc.)
> 
> or
> 
> 2) Use the crazy-non-standard-web-server-hack that I made to automagically
> serve them a text file with line termination strings appropriate to their
> DAV Client's OS.

I don't think either solution is satisfactory.  I would setup the server
to push CRLFs for text files (being careful not to screw up unidentified
files) and push to get the clients fixed.  For inbound data, the hack
might be good if you have a useful ContentType header coming from the
client, but what a mess to maintain....

> The same problem as before; should I push this problem to the clients, or
> accept the problem and own it?

There are thousands of potential applications that may produce or process
text. You do NOT want to try to push this on them.

There are a limited number of WebDAV clients and servers.  Lobby them all
adhere to the established on-the-wire standard, and then every other
text processing application in the universe will magically be compatible
with DAV.

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------

_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.