fsfe-uk
[Top][All Lists]
Advanced

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

[Fsfe-uk] File format import/export


From: Simon Waters
Subject: [Fsfe-uk] File format import/export
Date: Mon, 04 Aug 2003 15:25:59 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Curiously I was pondering this very topic yesterday whilst not
concentrating on something in the kitchen, kind of sad person I am.

Specifically the question of when will MSO get an Import or Export for
OO format documents.

Whilst a module to import/export OO might seem useful to the users (an
itch), writing it (a scratch) would increase the utility of MSO. The
increase in utility for OO users might be higher whilst it is a minority
system but.....

Ultimately more utility and less interoperability issues occur if OO is
installed at the other end. I believe this is the route we should press
for, as it will give people a better experience of free software than
they have had of proprietary incompatibility*.

Technical barriers to this (bandwidth/disk space) are I think a red
herring. I may be stuck with ISDN, and old PCs, but for general purpose
Office computers sold in the last 2 years OO fits fine, as it will for
newer home PCs. Actually it runs kind of okay here on P200's with 64MB.
Broadband is now widespread. OO beta version is on the cover disk of
Linux User and Developer this month BTW, I assume just the Linux
version, haven't looked at the CD yet. One off 40MB downloads are not so
painful.

Microsoft typically provide import formats for competing applications,
as this is a requirement to migrate to your product, so expect an Import
function for OO from MS when they decide the potential market gains
exceeds the increased ease of life for OO users of such a function.

Whilst I agree that Office format documents are not the technically best
way of doing consultations or surveys, or getting multiple document
modifications to review and merge, it does utilise tools readily
available to the civil servants in question, which may make it the most
practical solution. So if they are going to do it this way, I'm with
Ian, it ought to be free (gratis) software they use to allow others to
consult without paying an IT tax to Microsoft, and I suspect it would
alos have to be FREE software to support a sufficiently broad range of
platforms.

Not to say a good general purpose survey/form design/consultation
website couldn't find a niche in eGovernment. But it has to be easier
and cheaper, or better than just wacking out a word processed document,
to both author and responder - remember the government doesn't
experience the responders pain when replying to government consultations
- - if anything more pain means less responses, and thus less work
collating those responses, even if it results in worse government.

The openness of the document format may be important to software
authors, from a practical perpective if I want to do some "red-lining"
style co-operation with Ian, I probably want him running exactly the
same version (or as close as possible) of whatever software is in use.

- From a practical perspective free (gratis) software has a big edge here,
as it avoids the difficulties of everyone having to get budget to buy
the same software. If FREE software can't win in this area it isn't
going to win anywhere.

We need to distinguish document format descriptions carefully....

It may be "open" as in fully documented and people are not prevented
from writing interoperable implementations , it was my understanding
Postscript and PDF (at least old versions of PDF met this).

It may still be proprietary in control of the standards, although I
think this is less of a problem as free implementations are not obliged
to go to newer standards. However it may be that proprietary features
are added (such as patent encumbered, or encryption!) which standards
controlled by more broad committees may not tolerate.

However a lot of this comes down to the trust you can place in the body
controlling the standard, and even that may change with time, like the
proliferation of companies on committees defining Internet related
standards.

Quite how much faith to put in companies like Adobe is a difficult one,
although I think perhaps they now begin to recognise that "goodwill" in
the company as a manager of the standards is as, or more important, long
term than their short term business interests. However I think Java
story is suggesting that the market may find that proprietary control
unacceptable. Microsoft may have shot themselves in the foot by making
such an issue over the management of the Java standards by SUN.

Am I alone in thinking that a free software implementation, may be a
better "standard" in some areas than a written standard, I certainly
think this was the basis of SMTP's success, because as a mail protocol I
doubt it would ever have got through a telecomms industry protocol
committee, but sendmail as a free interoperable implementation made SMTP.

Similarly Winboard protocol became a major player in the Chess world by
happening to be how GNU Chess 4 and Xboard/Winboard talked, others could
refer to the programs as a reference implementation. That is not to say
I don't think makin the protocol or file format "explicit" is a bad
idea, many of the flaws of these protocols comes from making them
"compatible" with the implementations that existed when they were
standardised.

 Simon, who was pondering this as a result of thinking that KDE 3.2 is
beginning to really show the snowball effect of free software, with a
fully integrated Desktop and related web/mail/PIMs features that begin
to make proprietary solutions look rather poor in comparison. Although
they could do with more big business users to get the hardware vendors
behind products like Linux PDA syncing software.

* And ultimately it is about better software for doing a job, although
better is a broad term.
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/LmzxGFXfHI9FVgYRAqYQAKCWtUFz0Am1Ul7xKsRL/h7w8PQSYwCfWsj+
/+Dcl5SL2Z/+e7NWnTtHTG0=
=/31g
-----END PGP SIGNATURE-----




reply via email to

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