Charles Dyer <charlesd[at]newsguy.com> wrote:
> On Fri, 27 Jun 2003 21:13:34 -0500, RPH wrote
> (in message <pleasedontspamme-6D1E80.19140427062003[at]typhoon.sonic.net>):
>
> >
> > can any Hogwasher user comment on its capabilities for downloading
> > binaries?
>
> The only major problem with downloading binaries (or anything else which was
> segmented, for any reason) is that Hogwasher is pretty strict about what it
> considers to be a segment. If it doesn't think that _all_ the segments are
> there, it won't download the file, not even as text so that you can
> hand-assemble it. This can be irritating when there're three segments, all
> three clearly visible, but set up in such a way that Hogwasher considers them
> to be three seperate segments of three different files, and so won't download
> _any_ of them.
thanks for the heads up on that. i installed hogwasher for the free
trial this morning and played with it. generally speaking, i like it;
it took a while to get my head around the very different approach it
takes to the overall task, as compared to MT-NW, but it didn't feel
'wrong', if you know what i mean.
> > i've been an MT-NW fan for years, but it has several
> > limitations (or missing features, call it what you will) for solid
> > handling of large binary downloads.
> >
> > i looked briefly at Thoth but decided it's not for me. not sure what
> > alternatives there are, even, outside Hogwasher. (note: i have not been
> > playing much with MT-NW 3.3b; i deleted it after less than a day, after
> > discovering its handling of binary threads that start with "0/N" lead-in
> > messages was completely broken.)
> >
> > needed features: complete lack of failure to halt all threads when one
> > thread puts up an alert (probably the worst thing about MT-NW in this
> > area);
>
> What do you mean by this? What kind of alert are you talking about?
i was being cheeky. :) when a binary extraction thread ends with an
alert in MT-NW, ALL current threads are halted until the alert is
dismissed. this is really, really annoying for unattended operation
(overnight). i mean... *really* annoying. :)
(common example: select a bunch of messages and extract binaries; if any
are incomplete, at the end MT-NW puts up an alert saying "couldn't get
some because they were incomplete"; yeah, i try to prune these out
before starting, but other failures can happen that i can't control,
such as messages scrolling off or flaky connections interrupting part of
the download.)
what i want is a program that *fails* to include this annoying feature.
:) my brief session with hogwasher today suggests it doesn't do this.
> > much larger than MT-NW's 25,000 limitation for header fetching;
>
> No problem, I see one subscription which has 30,000 headers, it loaded them
> without a problem.
noticed this right away. yay!!
> > smarter header fetching for sparsely read groups (MT-NW fetches tons of
> > individual headers in this case-- can take a half hour, over DSL, to
> > fetch headers for a popular group that I have intermittently marked as
> > read the previous day).
>
> Hogwasher doesn't reload headers the way the Newswatchers do. You download
> the headers _once_, and there they stay, until they expire on the server
> (Hogwasher periodically purges expired headers, so you don't have to) or
> until you remove them.
noticed this, too, right away-- actually suspected it would be the case
when the FAQ discussed offline operation. again-- yay!
my only beef so far is binary extraction is a two-step process when
you're browsing -- by "browsing" i mean while interactively perusing
headers, as opposed to using filters. there are newsgroups that i scan
on an occasional basis. for these groups, i am unlikely to set up any
filters; i just scan them irregularly, and fetch whatever appeals to me
on the spot. getting those binaries requires (so far as I can tell)
first a download (to get them into the local database) then an extract
command to get them out into the Finder. for large binaries, this is a
really bad waste of resources (the data still exists in the message
database until i delete it).
and the filter solution appears not that great to me-- there is a filter
option for "download, extract, and delete [from the database]"; however
this is only really useful for things you can definitely and
unambiguously filter for. again, bad for on-the-fly downloads of stuff
that catches my eye. i would really like a one-shot command for use
while browsing interactively. (basically, i want the extract command to
work whether or not the message is downloaded -- and have an option
where if it's NOT downloaded, an extract operation does not leave it in
the database afterwards. for anything multi-segmented, the database
entry is *useless* wasted space.)
[this all stems from the database-centric handling of messages; i think
the majority of users, esp. heavy users, would much rather the software
think in terms of delivering binaries into the file system, to be
consumed by other apps (iPhoto, iTunes, etc.)]
one other not-so-minor quibble: save-as-text does not include all
headers (not even when you have full headers turned on while viewing the
message). it doesn't even include the date, which basically makes it a
non-starter for any kind of serious text archiving.
i can see, though, that i might switch to it for binaries and stick with
MT-NW for text.
> > nice-to-have feature: ability to pause (not merely cancel) a download
> > thread.
>
> That it doesn't have.
ah, well... something for the suggestion box...
thanks for the detailed reply!
--r