A month or so ago I wrote a rant about how Dantz should work with
Alladin and come up with a better compression scheme.
I know that the on-fly compression is difficult to maintain speed,
but it seems like better than 2:1 should be possible. I'm not much
of a wiz at all with compression, however I see modems getting
v.42bis (4:1) on the fly, it seems like a little work and this should
be possible for client and server as well.
Yes, I know that advertised and what you really get are totally
different, but all I know is that if something is advertised at 4:1,
it will be more likely to get at least 2:1 that 2:1 is likely to.
Alladin is cross platform. Dantz covers the same platforms.
Yes, most people use hardware compression, but this is mostly because
the hardware and software compression are likely to get the same
Why would anyone want to write their own compression? I mean, a
license deal from Alladin, who's been doing it since the early days
of Mac, would seem like it would be far more cost effective.
>It'd be really cool if the clients would compress the data before shipping
>it off to the (slow) network. I think we'd see better backup rates,
>especially since compression is so fast on today's computers.
>It wouldn't have to be much compression - kinda like PKZIP's "-ef" or "-es"
>switch (for FAST or SUPERFAST compression). Even a meager 10% compression
>would be a significant improvement.
>Decompressing at the server would be optional (Perhaps necessary to provide
>backward compatibility with restores to older clients that don't know what
>compression is. Then again the server would know the version of the client
>and whether the client supports compression.). I'd prefer optional, and let
>the tape drive hardware compression further compress the data if possible.
>Of course I'll leave the implementation details to Dantz. ;-)
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.