[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: Bug#16103: koffice should compress the documents with bzip2 too
From:       Christian Lavoie <clavoi14 () po-box ! mcgill ! ca>
Date:       2000-11-27 2:20:20
[Download RAW message or body]

> > Point is, again, do not expect people to use KOffice the way you do, the
> > way you planned it to be used, etc.
>
>   I am sorry, I am on the opposite opinion. I don't know any better way of
> designing a program than thinking about the way in which the immediate
> user can use it. We went into BIG problems when we tried to anticipate a
> too big leap in usage patterns (do you remember CORBA in KDE?). (No, I
> don't try to say that bzip compression would make the same problems).

No, I don't remember CORBA in KDE. My attempts at involving myself are too 
recent. Please keep it in mind. (I might bring back things that were long 
agao voted against, for the very good reason I don't know they were voted 
against)

I still fail to see why it should impossible to have multiple compression 
algorithms natively.

1) It doesn't imply an awful lot of modifications to existing code, as I 
doubt that all KOffice apps have their own implementation of the document 
decompressing.

2) Good compressors do have specilized algorithms (or sub-algorithms) for 
different situations.

The thing is, as opposed to CORBA-KDE, bzip2'ed KOffice documents do not 
imply major restructuring, nor major recoding. I doubt there is an awful lot 
of KOffice-><whatever>  filters out there too.

>   The current trends are:
>
> -very cheap storage: the size of office documents do not matter anymore.
> -increasingly cheap bandwidth.
> -users being sensitive to program responsiveness.

Agreed. Most users fit in this category. But some don't. And not caring for 
the last 10% of people is just a big mistake. (see below for my point-of-view 
on current trends)

>   Your argument regarding VRML is a different problem. VRML is not a
> native KOffice data type. It is the responsability of the virtual reality
> folks to define their own data formats. We did not try to define a KDE
> MP3, AVI, JPEG etc formats - why would we do it for VRML?

I don't recall saying: "Let's write a KOffice version of VRML".

But what about embedding a VRML document in a KWord one? I fail to see why 
_allowing_ for bzip compression would be bad. Most file formats you 
mentionned have one common trend: They have internal compression. Why? Even 
as bandwidth goes cheaper, storage space increases exponentially, etc. 
People's need grow even faster. And, while it's not our business to patch the 
VRML standard where it fails, it _is_ our business to circumvent its flaws 
where we sanely can.

Currently, the trend is to non-compressed file formats. XML, and all of W3's 
work rely on external compression. Indeed, the network protocol can do an 
awful lot there. But not everything.

Whereas 'yesterday''s file formats where binary exceedingly small files, 
today's internet standard are growing fast in size: SVG, VRML are just two 
obvious examples.

As a last argument about supporting bzip2, it is part of the gzip2 project 
(which basically never took off) [see slashdot's interview with the gzip (it 
might be bzip2) author], so why just might end up supporting it in the 
future, whether we like it or not.

>   On the other hand, when you transfer files on the network you can employ
> compression, there are many ftp servers/clients which do that. But this is
> the bussines of the network transfer algorithm, not a responsability of
> data format designer.
>
>           Lotzi

-- 
Christian Lavoie
clavoi14@po-box.mcgill.ca
UIN: 947212

[prev in list] [next in list] [prev in thread] [next in thread]