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

List:       koffice-devel
Subject:    Re: Changes to koffice/lib/store
From:       David Faure <david () mandrakesoft ! com>
Date:       2000-11-12 12:18:26
[Download RAW message or body]

On Sunday 12 November 2000 10:42, Werner Trobin wrote:
> 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).
[snip] 
> What do you think?

Sounds good to me.

> - We have a more accurate SPEC with less loopholes ;)

Not really. That's something else. You still give full control to the apps/parts
about the naming, so the loopholes in the SPEC remain the same. It's just
that parts know their children as relative URLs, since apparently this makes it
easier to move parts around (like embedding an existing part with sub-objects
into a new parent document - that's the goal, right ?).

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://www.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today
See http://www.kde.org/kde1-and-kde2.html for how to set up KDE 2
_______________________________________________
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]