[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Re: File-tpye plug-in architecture for Arch?
From: |
michael josenhans |
Subject: |
[Gnu-arch-users] Re: File-tpye plug-in architecture for Arch? |
Date: |
Sun, 21 Dec 2003 15:11:17 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 |
Thomas Zander wrote:
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.
My idea would be to make tools like OO patchset-aware. The current way
of change tracking does not work according my understanding very well.
This is not an OO-problem, but rather a revision mangement problems all
office suites face that I know.
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)
It is actually my motiavtion. Even an OO-change tracking mode could be
implemented starting the initial files. When changes are added, patches
could be stored as patchsets by OO in the OO-zip file container
invisible to the user, maybe in a different revision history directory.
This would enable revison tracking for the sake of loading speed and
eventually branching for the sake of loading / saving speed.
When change tracking is disabled, all patchset could be merged
immediately when saving.
The hard part is walking through the history at that point; which will
probably be a OOo only GUI.
I think diff3 is only one representation for patches. Depending of the
information content, other reprentation formats might be more
appropriate. In OO-case one useful option would be a change tracking mode.
> 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.
I would not like to merge a spreadsheet table with a diff tool, which
does not know what a cell, a color or a formula is. Only geeks would
like to that.
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.
I agree here. But first we should understand patching of XML files and
their limitations.
Example:
When you make a word in the OO-writer bold and another word underline.
The OO-filer seens to create 2 new styles nodes with the attributes 'T1'
and 'T2' in the file 'content.xml':
<style:style style:name="T1" style:family="text">
<style:properties fo:color="#800000"fo:font-weight="bold"/>
</style:style>
<style:style style:name="T2" style:family="text">
<style:properties fo:color="#800000"
style:text-underline="single"
style:text-underline-color="font-color"/>
</style:style>
and addes the tags to the text:
<text:p text:style-name="Standard">This is a very very short text
<text:span text:style-name="T1">written</text:span> with open
<text:span text:style-name="T2">office</text:span>.
</text:p>
Using tags as enumerations like 'T1', 'T2', etc. Is very branch
unfriendly. An arch like solution would likely be, if tags contain the
branch name. Like: 'Branch_1:T1', 'Branch_1:T2' or 'Branch_2:T2'.
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
Thanks for the link.
As a first goal I would see, making arch xml aware and eventually able
to work with zipped directories.
Michael
- Re: [Gnu-arch-users] Re: revision control for documents (was plug-in foo), (continued)
- Re: [Gnu-arch-users] Re: revision control for documents (was plug-in foo), Thomas Zander, 2003/12/23
- Re: [Gnu-arch-users] Re: revision control for documents (was plug-in foo), Thomas Zander, 2003/12/23
- Re: [Gnu-arch-users] Re: File-tpye plug-in architecture for Arch?, Aaron Bentley, 2003/12/22
- Re: [Gnu-arch-users] Re: File-tpye plug-in architecture for Arch?, Andrew Suffield, 2003/12/22
- Re: [Gnu-arch-users] Re: File-tpye plug-in architecture for Arch?, Aaron Bentley, 2003/12/22
- Re: [Gnu-arch-users] Re: File-tpye plug-in architecture for Arch?, Andrew Suffield, 2003/12/22
- Re: [Gnu-arch-users] Re: File-tpye plug-in architecture for Arch?, Momchil Velikov, 2003/12/23
- [Gnu-arch-users] Re: File-tpye plug-in architecture for Arch?, michael josenhans, 2003/12/21
Re: [Gnu-arch-users] File-tpye plug-in architecture for Arch?, Andrew Suffield, 2003/12/19
[Gnu-arch-users] Re: File-tpye plug-in architecture for Arch?,
michael josenhans <=
Re: [Gnu-arch-users] File-tpye plug-in architecture for Arch?, Aaron Bentley, 2003/12/19