pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-users] Interesting stuff about yEnc


From: Charles Kerr
Subject: Re: [Pan-users] Interesting stuff about yEnc
Date: Mon, 25 Mar 2002 09:36:31 -0800
User-agent: Mutt/1.3.20i

On Mon, Mar 25, 2002 at 06:06:22PM +0200, Gabi Davar wrote:
> After a _very_ quick read here are my thoughts.
> 
> * reliance on magic string to specify start
> * bad subject line specification
> * bandwidth saving is an illusion
> * transition time
> 
> That's about it.
> From my experience of implementing yEnc decoding, these points are minor to
> say the least. The first issue is not worth thinking about (XML doesn't use
> magic strings?). Subject line specification is merely a suggestion and is
> handled very well in the body itself (actual filename and part offset), and
> there always will be a transition time.

Well my debating this is moot, because yEnc is here and we all like it
(including me), but just for fun anyway...

Reliance on magic strings is a very frustrating thing, because it requires
Pan and other news clients to walk through text messages looking for these
strings.  Even for users who never look at binaries, Pan is wasting cycles
looking for yEnc and uu on each & every message.  It would be more efficient
to code these into the header.

> But what really bugs me is his thing about BW saving begin an Illusion. I
> guess being able to download three large binaries in a day on a 500MB
> account instead of one is a just my imagination :-)

:)

He's looking from the POV of a Usenet sysadmin, not a Usenet end-user.
yEnc doesn't address the bigger question of binaries in Usenet, which is
his gripe.  But so long as we've got binaries, yEnc is a big improvement
over uu or base64. :)

> His solution is basically lets wait till MIME gets better. My answer Why?

MIME is a universally-accepted specification for definining attachments,
encodings, filenames, and so forth.   The *only* thing yEnc brings to the
table is a clever & useful encoding -- it would be better to add that 10%
to MIME than add 90% to yEnc.

I don't have anything against the people who wrote yEnc.  They've put more
work into efficient binary encoding than I have (and more importantly,
than the Usenet mime camp have).  I'll enjoy yEnc for now just like everyone
else, and hopefully yEnc will drive faster evolution of MIME binaries specs.

cheers,
Charles



reply via email to

[Prev in Thread] Current Thread [Next in Thread]