gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gzz] Re: [ba-unrev-talk] Starting Point for Collab Tool


From: Alatalo Toni
Subject: [Gzz] Re: [ba-unrev-talk] Starting Point for Collab Tool
Date: Wed, 19 Feb 2003 13:03:06 +0200 (EET)

On Tue, 18 Feb 2003, Eric Armstrong wrote:

i quote a bit extensively as this is to inform others about your work,
too (gzz dev cc'd). but there is a specific question to you about the work
done in the gzz project, in the end, after a few comments to your post:

> I think I see a viable way to get resources devoted to
> the development of a remote, persistent collaboration tool.

seemed viable indeed.

> The train of thought began with a consideration of the "ABC"
> organizations that Doug Engelbart described in the Unfinished

i haven't got such insight of all those constructs so was quite
enlightening to read your summary and thoughts about it.

> Revolution colloquium, and ended with the view that software
> standards efforts provide the ideal "entry point" for the design
> and development of collaboration tools.

interesting point. i guess i really don't need to say this to someone
affiliated with Sun, but networking standards are clearly another (i'm
a little involved in isoc(&ietf)).

> This article describes that vision:
> http://www.treelight.com/software/collaboration/abc.html

there you linked to
http://www.treelight.com/software/collaboration/Technical_Impediments.html
which is what i'd like to ask you about:

if you have the time &/ interest to read the publication that's attached
as a pdf here, do you think that system would meet the requirements?

the code is in the cvs, but in quite a flux as changes are being
discussed, but the requirements and design is what i'm asking about here,
and there what's in the article should be accurate. it's just submitted,
so i'm sending this privately instead of the list -- if it gets
accepted and especially as soon as we have implemented more of it the
project will naturally be more ready for wider publicity.

already at this point, however, i'd very much appreciate hearing your
opinions (and believe that they might well be beneficial for others,
perhaps the actual designers of the system, as well). and of course, if
there's anything you might apply, it's all free and available.

if you allow, here's a quick short note of how it seems to me:
(i hope your mail client uses a monospaced font (or renders rst :))

treelight-collaboration/Technical_Impediments vs. Gzz/Storm
---------------------------------------------    ----------

=======================        =======================
issues from impediments        how Gzz/Storm addresses
=======================        =======================

Global Identification          Storm: block-ids (sha-1), (docs urn-5?)
Dynamic Links / Active Links   Storm: reverse indexing?
Localized Paths                (out of scope of Storm, could be done)
Granular Addressing            Storm: blocks, spans - perfect granularity?
Versioning                     Storm: pointers, diffs - nice?
Typed Links                    (out of scope for Storm, must in Gzz)
 - global ratings               - discussed in the article, should work
Composite Documents            Gzz-Storm implements transclusions
Meta Data                      changing: Mime -> metadata blocks
Tower of Babel                 Gzz is Java, Python, C(++), (Perl?),.. :)
Malleable Archives             Alternative versions (forks?) are supported
Authoring Tools                Gzz has own, also the format might be RDF
Component-level Programming    don't too much of this, sounds nice indeed?
Extensible, Integrated Systems (G)zz applitudes are within the system,
                                data (in Storm) accessible to any?

on, metadata, there's a current proposal:
http://mail.gnu.org/archive/html/gzz-dev/2003-02/msg00059.html
and in any case metadata must and will be supported.

finally: The Minimum Necessary Configuration. hm what to say. hopefully we
get something running and evolving? and get rid of unnecessary
complexities before that, e.g. as Benja is doing in that metadata
proposal? so hopefully we will have this "simple collaboration tool" and
.. uh, forgot was about to say, but guess this is enough :o

~Toni

P.S. as this message is cc'd to the list i'll send the attachment
to you separately, not to waste everyone's resources.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]