[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Mediaserver and Xu
- To: ZZ Development <zzdev@xxxxxxxxxx>
- Subject: Mediaserver and Xu
- From: "B. Fallenstein" <b.fallenstein@xxxxxx>
- Date: Mon, 25 Mar 2002 04:52:51 +0200
All,
Tonight I realized something I consider important: it is actually
*trivial* with the Gzz Mediaserver to build a local index of transcluded
spans, making it possible to find all transclusions of a span available
on the local system. It's very similar to the way we cache pointers.
Say we have a block with media content, with ID xyz. Mediaserver
internally stores it as a file called b_xyz. Now, a Gzz space makes a
transclusion from block xyz. Then we create a sister file called s_xyz
(for 'span'), and add one line that identifies the transcluding space,
the span it transcluded, and where in the space it was put. If another
space creates a transclusion, too, we add a second line to s_xyz with
the corresponding data.
Reading in these files can be expected to be reasonably fast, because
each content block contains only a *small chunk* of content; thus, there
won't be *that* many transclusions from it at least in the beginning.
Once we run into speed problems, we can optimize further, but I think
this will already take us quite far.
The question is then more one of user interface-- which transclusions do
we actually show? I think we'll want to try to find the 'newest' version
of each transcluding space through some algorithm. Then we could include
these temporarily as primitive (non-editable) slices when needed, and
show the transclusions. (We can also trivially create content links in
Gzz through that mechanism.)
This would give us a nice usable chunk of the Xanadu model with
manageable effort. And if we get the interfaces right, hopefully we can
sometime in the not-too-distant future implement a bridge to some
peer-to-peer network on the mediaserver level, creating a small but real
xu implementation.
- Benja