[MORK] brief syntax summary related to MDB usage

18 views
Skip to first unread message
Message has been deleted
Message has been deleted

Jeff De Luca

unread,
Mar 19, 1999, 3:00:00 AM3/19/99
to

David McCusker wrote:

> (Keep in mind I'm fond of saying that most hard DB problems concern
> exactly what is meant by object identity in various contexts.)
>
> Jeff De Luca wrote: [ snip ]
> > > { 1:cards {(rowScope=cards)(tableKind=Johns)} 1 2 }
> >
> > Interesting. I have to know though that the two Johns are in row ids
> > 1 and 2. If a third John is added, it is not present in the table
> > above - correct?
>
> Right, that table contains only rows that someone decided explicitly
> to add to that table. The membership does not change dynamically by
> some rule (such as rows containing some John name). At least, that's
> how MDB uses Mork, and some other Mork client could act differently.
>
> Technically, Mork is just a way of encoding content, and doesn't
> actually have an interface for usage. So my comments describe MDB's
> interface semantics, which do not define membership by rule, and not
> some restriction in Mork. Some client could use Mork for encoding, but
> decide to define table membership by rule, unlike what I say above.
>
> > What is the oid of this table - 1? I'm confused here.
>
> Interesting that you caught that. I did a lot of thinking yesterday
> about that table oid equal to 1:cards, since that table contained a
> row also with oid 1:cards. (Is that wrong? Was it a typo? Or can
> you have tables and rows with the same oid without conflict? Does
> this fit the earlier specified semantics in the MDB interface?)

Don't know. I've not seen these earlier specified semantics. I presume these
questions were rheotrical anyway.

>
>
> > You say that table ids also come from the row id space but this is
> > table 1 comprising rows 1 and 2. 1 is duplicated.
>
> The original MDB spec I posted (at least the comments in C++ headers)
> deliberately tried not to specify whether row oids and table oids
> were distinct, so that an MDB implementation would have the most
> freedom to do that however worked best. The API lets one pick the
> oids for rows, but not for tables. (You say, give me a new table,
> but you get whatever table oid is handed to you, and they might or
> might not be distinct from row oids in the same name space.)
>
> However, David Bienvenu expressed a wish to be able to specify the
> oid for a table when created, so if I support that then I have to
> take a specific stand on the oid uniqueness issue, and that will
> place a restriction on all MDB implementors. (Probably that's okay,
> since most folks like very strict marching orders for coding.)
>
> In both the MDB interface and in the Mork grammar, a row oid and
> a table oid always occurs in a context that makes clear whether the
> oid is a row or a table, so one can feasibly use the same oid for a
> table and for a row and not have an ambiguity conflict (unless some
> runtime assumed that a naked oid was enough to disintuish them).
>
> In the current Mork runtime that I have implemented, duplicate oids
> will be generated for rows and tables, since independent counts are
> used for rows and tables in the row space runtime construct. And
> it was feasible to do so because the APIs make the usage unambiguous.
>
> I'd like to keep it this way, because it simplifies the code that
> would be necessary to resolve conflicts that might happen between
> rows and tables. It's easier to have a row and table subspace in
> every oid namespace, so I'll stick with that unless folks scream.
>
> When I said table oids and row oids came from the same namespace,
> I meant that oids are always allocated in the space that Mork calls
> the "rowScope". However, since yesterday I've definitely decided on
> the policy of keeping row and table oid subspaces inside each space
> identified by rowScope name. So a table can have the oid of a row.
>
> However, unless I change the MDB interface to permit clients to
> pick table oids, I don't have to expose this Mork policy to clients,
> so you don't need to know from the interface whether row and table
> oids are distinct. However, since you can't know whether they are,
> you must write code that assumes they are not. So I might as well
> specify that in the MDB interface, and let clients pick table oids.

Hmm, I'd rather you generate them and assure they're unique. But I don't
really grok the client interface so I'm big-time presuming here that clients
don't want to be bothered with the management of oids, they only want them
as handles.

>
>
> You might be worrying about the case where one holds a reference to
> some object by it's oid, and you are worried about how to tell a
> row oid from a table oid. In Mork, one can ref a table or row by
> oid inside a cell by using the 'r' or 't' notation, where in each
> case the row or table status is clearly indicated.

Yup, I presumed there must some type info like that.

>
>
> The following card has cells referring to both the two earlier
> John cards, as well as to the table containing both those rows:
>
> [3:cards (uncle r1:cards)(cousin r2:cards)(johns t1:cards)]
>
> > You explain cells, columns, atoms pretty well.
>
> I actually didn't explain all the possible syntaxes that can show
> up inside a cell. Basically the first nonwhite character that
> follows the column indicates how the value is encoded. A value
> expressed immediately appears after '=', and '^' introduces a
> hex ID value into a dict. Similarly, 'r' introduces a row
> oid reference and 't' starts a table oid reference. Another
> way to introduce immediate strings is with "'" and '"', where
> these quotes enclose a string with no escape syntax currently.
> If more than one value definition follows the column name before
> the terminating ')', then they are all concatenated. Note that
> nothing can follow a value started with '=' since the ')' ends
> the cell as well as the value. I need to make up some syntax
> to indicate the value is b64. What do you think? #64"<b64>"?
> That would let one specify the radix after '#'.

Hmm, sorry if this is a dumb question, but... with the use of all these
special characters is internationalisation a problem? Are # and ^
translatable code points? I presume your files are not treated as binary
files since they contain so much text (messages). Is unicode handled? Can
content be unicode or double-byte character sets?

>
>
> (Note that dicts have no identity. All the dicts can be run
> together without changing the semantics. Each time dict syntax
> is used, it means "oh, here are a few more value aliases to put
> into the well-known global dict, which has named subspaces".)
>
> The concept of atoms is mostly a implementation artfict of the Mork
> runtime I'm writing. The required Mork semantic is that cells contain
> values, but the fact that something called an 'atom' might represent a
> value at runtime is not required. However, Mork uses "atomScope" for
> a name space for values, so I'm making my terms a bit blurry there.
>
> Maybe that should be "valueScope" to straighten out my terminology.
> But in practice I don't mind some ambiguity in language to describe
> a system, as long as the ambiguity does not appear in the code APIs.
>
> > But I'm confused with rows and cards. Same or different?
>
> A row is a Mork and database level concept, and it amounts to mechanism
> that you can apply any way you like. The concept of card means nothing
> at all to either Mork or MDB. Rows and cards are different to Mork.
>
> A card is an application level concept, and is encoded using a policy
> that uses a row to represent each card. For an app using such a
> policy, such as a hypothetical address book application, row and card
> mean the same thing. Except that even in such an app, rows would be
> used to encode yet other things that are not cards. So every card
> would be a row, but a row would not necessarily be a card. (Just like
> every square is a rectangle, but not every rectangle is a square.) So
> for such an app, a card would effectively be a row subclass.
>
> > What's the purpose of the :cards syntax?
>
> In the fragment of Mork grammar below, zm:Id is the syntax for an oid:
>
> zm:Hex ::= [0-9a-fA-F] /* a single hex digit */
> zm:Id ::= zm:Hex+ (':' (zm:Name | '^' zm:Hex+ ))?
> zm:MoreName ::= [a-zA-Z:_+-?!]
> zm:Name ::= [a-zA-Z:_] zm:MoreName*
>
> The purpose of either ":namespace" or ":^FACE" is to qualify a given
> hex ID as belonging to a specific name space, so that integer IDs in
> one space will not conflict with integer IDs in another space. This
> is intended to permit a Mork database to contain content for entirely
> unrelated applications that allocate IDs in independent fashions. So
> if an app uses unique ID namespaces, it's content can be added to any
> Mork database without having a collision with another app's content.
>
> > Can I create tables based on query or select type criteria? e.g. where
> > ^93=John. How would an mdb client do such a thing?
>
> The MDB interface I posted has no method that does that, because the
> mail/news and address book applications did not have any need to do
> such a thing. You could make an MDB superset with such a method, but
> it would be ignored currently unless some Mozilla code needed to call
> such a method later. We don't want to have methods in the MDB API
> that are not really needed, since this makes it harder to implement
> the interface on top of various databases, given more requirements.
>
> David McCusker, speaking only for myself, mozilla mail/news client eng
> Values have meaning only against the context of a set of relationships.


Reply all
Reply to author
Forward
Message has been deleted
0 new messages