Re: plans for reference management

Hi Martijn, Roman:

[...]
>> But it may be too late after publishing the document that an author is
>> informed about broken links. So, he has to alter and
>> publish the document again to fix the broken links. That are to steps to
>> get a document with correct links in it. But you're right, if the
>> document contains a vast amount of links, it'll be overkill...
> 
> 
> How slow is checking a link for existence in this system? If this is 
> reasonably fast, then it's quite doable to do it on every kupu save. 
> Harder, especially due to the feedback to user issue, might be the forms 
> editor, where only parts of the document get edited, and you don't want 
> the whole document be checked each time. You could of course extract the 
> links from only the part but it'd be hairy.
> 
> Perhaps Clemens' later proposal about a button to check references makes 
> most sense, especially as a first step.
> 

  If I understand the lms correctly it is about first registering the
links with the link checker; the results can be fetched later.
So it is maybe not too inefficient on the Silva side just to register
the link (it may be inefficient for the lms to check them while
they get swapped away with the next edit). Even less performance problems
for references, I guess.
  The reason why I initially thought about checking the links on approval
is that after approval it seems to make some sense to me to include
the references into reference management. However there seems to be some
consensus we should not talk about that now but target at goals closer by,
so that idea goes off topic.

  Again, if I understand the lms right, one could have a simple summary
(including a "check in progress" stat) on the main edit page relatively cheap.
Having the full report in an extra window seem the most practical solution
to because users most probably want to keep the report around while fixing
the links ... having this on top of the edit page or in a separate tab
seems impractical to me. Some automatic status update via some
brute force http-equiv="refresh: ..." is rather easy to implement, too.

[...]
> I've done the simplest thing I could think of, which is to offer a 
> section of the Infrae CVS for such projects. So here's the Zone:
> 
> http://cvs.infrae.com/zone/
> 

  Ah, great, thus Roman and me do not have to toss a coin about
who is registering what and where .-)

  I better do not try to mess with "cvs import" this evening ...
but will look at it this week.

  Roman: is it ok for You if I dump in an initial revision of the
SilvaReferenceChecker to the CVS, or would You prefer to create
a fresh "SilvaLinkChecker" in the first place?

  Looking in the cold ashes of my last attempt to improve the reference
service (quite a year ago ..) I found ruins of something which tried to do
something vaguely similar to the "LinkDatabase" of the CMFLinkChecker
-- i.e. store the links/references so they do not have to be fetched
on every run. As this would have replaced the current "SilvaReferenceChecker"
anyway, by importing my sources I do not mean to make any predecision
about how to proceed, e.g. if to port CMFLinkChecker or just port the part
using the lms and grow its own instead.  (We can reuse the part retrieving
the references anyway, I hope.)

  Well, importing something would make a decision about the name, I guess ...
(at least until migrated to subversion ... ;-)
  Any opinions?

Cheers,
Clemens