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

List:       koffice
Subject:    Re: KOffice Storage Structure
From:       "Shaheed Haque" <shaheedhaque () hotmail ! com>
Date:       1999-08-17 7:01:15
[Download RAW message or body]

Date: Tue, 17 Aug 1999 08:01:14 BST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

A couple of thoughts/ideas for the storage structure

1. I like the idea of storing some metadata about the top levelobject. I 
think this should minimally include Author, Last Modified Date, Title, 
Version (all as strings, with the GMT/UTC date in YYYY-MM-DD HH:MM:SS 
format). This is probably the minimum set of information required by 
document control systems for formal documents.

2. The type of embeded documents might be stored by their CORBA interface 
name? That would avoid "guessing/sniffing", but we might want to add the 
ability to store non-CORBA objects (not sure of an example). The mime-type 
is another possibility, but then we'd need a mapping from mime-type to CORBA 
interface.

3. I think we must separate the contents of the embedded object from use. 
For example, a KWord document might contain several "views" of a K3dCad 
drawing which we would not want to *store* multiple times. Perhaps the 
structure should be conceptually like this:

structure := metadata list-of-parts... part-data-array...

list-of-parts := { generated-label | user-defined-label } '='
                 { external-URL | embedded-part-id }

embedded-part-id := CORBA-interface-id part-data-array-index

and where each part-data contains one object (the first one is the top level 
object). One object refers to another object using the label and some 
instantiation information which is dependent on the object type (e,g, to 
allow front or rear views of a KHouse object).

Hope this helps, Shaheed


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

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