gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] File-tpye plug-in architecture for Arch?


From: Thomas Zander
Subject: Re: [Gnu-arch-users] File-tpye plug-in architecture for Arch?
Date: Fri, 19 Dec 2003 08:49:00 +0100
User-agent: KMail/1.5.94

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

On Thursday 18 December 2003 23:50, michael josenhans wrote:
> Hello,
>
> arch as a version management is currently designed to work with:
> - text files
>
> the diff tool is designed to work with:
> - text files
>
> the patch sets:
> - are stored as tar files
>
> Should be a plug-in structure available to adapt on specific types.
>
> In current discussions, we see people requesting to use other storage
> formats for patchsets (see discussion on 'Re: patch-log sizes') or
> use it with other file types. E.g. XML- or SGML-files (see discussion on
>    'Re: arch and bookmark maintenance').
> For XML- or SGML-files a diff tool supporting automatic conflict
> resolution considering the XML/SGML syntax and eventually even the DTD
> would be useful.
>
> In extreme arch could be used for version management of
> OpenOffice-files, while are zipped XML-files.

In KOffice and on OpenOffice there have been on-and-off discussions on 
saving the file to a filesystem layer like 'cvs://'.
This touches the same idea, and sidesteppes some problems your solution 
will face.
Since OOo will save some 5 different XML streams inside a zip file its 
quite easy to do revision management on XML only streams once you have a 
XMLDiff application in place. (which should be first priority)
The hard part is walking through the history at that point; which will 
probably be a OOo only GUI. Simply because they need to what the changes 
mean on screen. That part will be done in the office suites and can be 
done with the current tla interface.


> Knowing OpenOffice's storage format and DTD structure by having
> OO-plug-ins, arch could create patch sets from the diff's generated from
> OO files. Eventually this would lead to a very interesting method for
> collaborative work on office documents and on change tracking.

I don't think this will work the way you think; the logic is in the wrong 
place if you put it in a tla plugin. The logic should be inside OOo to 
match changes there, and to be able to resolve problems based on 
intelligence that only OOo can have.
Think about specific problems you have to solve in this program only to 
find out you don't have the data-structures to do it.
Notice that a DTD can change and you have to chose based on the file being 
offered to you.

> Likely it would not work with current OO-files very well, but could arch
>   as background infrastructure potentially provide change tracking and
> collaborative document work into such environments?
>
> Let's hear your opinions.

There is work going on on the XML streams formats which OOo (and probably 
other office suites) are going to use in the near future. Last time I 
participated in those discussions there were hooks in place to allow this 
kind of functionality specifically (in the file-format).

I think you should talk to them before you do anything.

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office

- -- 
Thomas Zander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/4q1wCojCW6H2z/QRAtSCAJ4isWJ+84UxZxrRVmYJLotAGuwGlACgvNCq
IJwLi8aI4ZgDTlYZKlTGmUk=
=sMQp
-----END PGP SIGNATURE-----




reply via email to

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