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

List:       koffice-devel
Subject:    Re: Changes to koffice/lib/store
From:       "Shaheed Haque" <shaheedhaque () hotmail ! com>
Date:       2000-11-12 10:49:18
[Download RAW message or body]

Werner, see my other note, just posted. As I say there, I'm starting to lean 
in favour of the other solution. But lets see what discussion produces. All: 
please move discussion of this topic to the other note:

http://lists.kde.org/?l=koffice-devel&m=97402560511379&w=2

to keep this one free for sorting out kspread-specific issues.

>From: Werner Trobin <trobin@kde.org>
>Reply-To: koffice-devel@master.kde.org
>To: koffice-devel@master.kde.org
>Subject: Re: Changes to koffice/lib/store
>Date: Sun, 12 Nov 2000 11:42:31 +0100
>
>Shaheed Haque wrote:
> >
>
>::snip::
>
> > Well, insulating apps from the details of the storage was a good idea, 
>so
> > I'm not yet ready to throw the baby out with the bathwater. As you know
> > (!!), the only thing controlled by koStore is the name of the part file
> > (maindoc.xml) and the level at which it occurs using well-known 
>directory
> > names (part0/part1/part0). The new design simply makes the top level 
>like
> > the other levels.
> >
> > Besides, the regularisation of part names might one day enable certain
> > things which are not thought of today.
>
>Shaheed and I had a little discussion about that on IRC
>yesterday. I'll try to mention the most important points
>and my opinion about all that stuff. Please tell me what
>you think about it and where you see difficulties or fuzzy
>specifications.
>
>1) We agreed that we have to stay backwards compatible.
>    This can either be achieved by adding some "legacy
>    code" in KoStore, or by providing a (preferably Perl)
>    script which does all the magic for old files.
>    I'm in favor of the legacy code solution in that case.
>
>2) We also agreed that it's a nono if a filter or application
>    has to know how deeply nested it is. This shouldn't matter
>    at all. Therefore we suggest introducing relative URLs in
>    KoStores. Due to that we'd have to extend KoStore and adapt
>    all the applications and filters.
>
>Basic thoughts about that extension/adaption:
>a) Every app/filter only saves its direct children and asks
>    them so save itself. Therefore relative URLs only have to
>    be one level deep. Shaheed pointed out that there are cases
>    for the OLEFilter where this is not true, but this is a
>    problem specific to this filter and should (and can) be
>    solved there.
>b) If we really decide to make KoStore a little more intelligent
>    we can also add some other nice features ;)
>    I propose to have tar:/0/1/2 and so on as absolute URLs in
>    KoStore, and tar:0, tar:1, and so on, as relative URLs.
>    We can also store absolute URLs to the "outside" world, then.
>    Think about file:/home/foo/mypicture.jpg or
>    http://www.kde.org/somepic.png as an absolute URL in any KOffice
>    document. The KoStore would be responsible to provide the
>    matching file (via KIO and what not ;).
>c) Pictures and parts are handled the same way. It doesn't matter
>    at all whether we save an xml file or a picture. The relative
>    URL has to be unique (maybe provided by KoStore?) and that's
>    it.
>d) As directories are cheap in tar storages we can just create
>    one directory by child and save the contents in there.
>e) We have to adapt all the applications and filters to store
>    only relative URLs. On loading KoStore "remembers" the current
>    directory and can be asked to provide a file by passing a
>    relative URL. As we load/save depth first it shouldn't be too
>    hard to implement it (in KoDocument).
>
>This would give us the following advantages:
>- Centralized "knowledge" in KoStore/KoDocument
>- The apps don't have to know the current "depth"
>- We have a more accurate SPEC with less loopholes ;)
>
>Disadvantages:
>- Unfortunately I won't have the time to implement it in the
>   next week(s)
>- We'd have to change all apps/filters (and the file format)
>- We introduce an incompatibility to 1.0 (and due to that need
>   some sort of legacy-mode)
>
>What do you think?
>
>Note: I wrote that very quickly, so I might have contradicted myself
>several times, forgotten major problems/issues, and made 1E6
>spelling/grammar mistakes. Please enjoy >;)
>
>--
>Werner Trobin - trobin@kde.org
>_______________________________________________
>Koffice-devel mailing list
>Koffice-devel@master.kde.org
>http://master.kde.org/mailman/listinfo/koffice-devel
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel

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