Charl (one of the students from Nijmegen) created a proposal
for
changing some things in the data-structure of Manta. It's
on-line
here, for those of us interested:
http://www.logilogi.org/pub/manta/req_diff_en_da
tastructuren.pdf
Charl is also on this list, so I will ask a few questions
about it
here, so he and others might give their views on them.
General remarks:
* First of all: the proposal gives a clear description of
the
current system, and contains an interesting proposal about
which I really would like to know more.
* An issue is though that I'd be interested in seeing some
benchmark-data. I suspect that not the saving and diffing
of
the text, but the resolving of links will take most time
in an
average-sized logi to which, say 4 new links were
added...
* I wonder how much of that would disappear if we
implemented the
diff-algorithm in C++, or if we wait for YARV
(http://www.atdot.net/yarv/
,
http://www.antonioca
ngiano.com/articles/2007/02/19/ruby-implementations-shootout
-ruby-vs-yarv-vs-jruby-vs-gardens-point-ruby-net-vs-rubinius
-vs-cardinal)
Ruby really seems to me to be the wrong language for
pointer-
juggling.
Links:
* A thing that should be taken care of is how the links will
be
resolved after one saves a logi as a new text. The current
procedure is to translate the link-positions to absolute
space
and then look at which links changed, and re-resolve only
those.
* For speed-reasons links must be pre-resolved (so we can
have
incoming links, and the link-drop-downs will load within
reasonable
time) what is your plan for this, especially as we don't
want
duplication of incoming links from different versions (I
could
imagine still using positions for links, but then we still
will
have to apply the diff-algorithm).
* It should still be possible to link to specific versions
after
this change (but this would not be a problem, as we could
add a
version-column to the logi-table)
Tags:
* I really think that tags should be applied to logi's and
not to
versions. Semantically this makes more sense, as logis
should be
short texts and be normally not editable by other authors
they
are not expected to change that often and thus to remain
fairly
stable at least semantically.
* Also it will keep some queries - like those for branches,
but
also link-resolving - faster (unless we would store old
logis in
a separate table).
* This does not mean that keeping Logis separate from
LogiVersions
would mean that we cannot duplicate the body-text in
LogiVersions
instead of in Logis. That might still be a good idea.
Editing:
* I think that this proposal jumps over the problem of
link-tags
inside the text a bit too quickly. Many people in the
humanities
would not like to see link-tags inside their text.
Especially
link-tags because those really break into the text,
contrary
to '''emphasis''', or = titles =.
* Having links in the text will even be a bigger problem in
manta
because other will be able to add links to your text even
if they
cannot edit it, so some texts could become quite crowded
with
links contrary to the wishes of the author.
* So we would really need a WYSIWYG-editor if links were to
remain
inside the text for all edit-modes.
This might seem a lot of questions and remarks, which is
true ;)
But they are mainly aimed at getting the proposal, and the
issues
involved clarified... surely not at keeping status quo, or
making
the proposed changes seem impossible...
greetings,
Wybo
------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
LogiLogi-list mailing list
LogiLogi-list lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/logilogi-
list
|