[silva-dev] plans for reference management

[Christian Zagrodnick]

On 18.04.2005, at 14:13, Martijn Faassen wrote:

> Roman Joost wrote:
>> On Sun, Apr 10, 2005 at 01:07:31AM +0200, Clemens Klein-Robbenhaar 
>> wrote:
> [snip]
>>>  Because updating the references each time someone edits a document 
>>> seems
>>> a bit overkill to me I feel the step of approving a document (or 
>>> some other
>>> versioned content) seems to be the right time to fetch the references
>>> contained in the approved version.
>> 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.

Well, most times it is reasonably fast. The lms just takes the links in 
and returns the results it already knows. It then, asynchronusly, 
starts checking and notifies the cms. We're doing link retrieving on 
every full reindex now actually. We plan to replace that by a separate 
catalog index though.

> [snip]
>>>  As far as I understand Romans intention he wants to go into a 
>>> different
>>> direction, e.g. improving the ability to check external links.
>> Okey, well yes, I never thought of developing a product which does
>> reference management. Just a product which checks internal and 
>> external
>> links like the CMFLinkChecker does. Sorry for the confusion ...
>
> It's useful anyway, I think a "let's keep it simple" and reusing 
> existing codebases like CMFLinkChecker is an excellent way to tackle 
> this hairy set of issues and get somewhere reasonably quickly. In the 
> past, when Infrae discussed these issues, we tended to be bogged down 
> by things like "when someone moves something, the links still need to 
> work!", which is extremely nasty in the details. If you can ignore 
> that, it should be simpler.

It is. The bidirectional thingy was a matter of a week or two.


>>>  Roman: If we want to coordinate our work on improving the current
>>> SilvaReferenceChecker checker, how do we do that? I do not have the 
>>> resources
>>> to set up a public CVS server or the like. I thought about an 
>>> archive at
>>> SorceForge maybe, but the last time I asked on this mailinglist if
>>> other developers of Silva add-ons would be interested in having some
>>> "Silva common add-ons" repository there I got no response thus I did 
>>> not
>>> tried that so far.
>> Well, such a "collective" sounds nice indeed. I think, I could use the
>> CVS server from gocept for such a product. If we have more extensions
>> for Silva and it makes sense to collect them in a sourceforge project
>> I'll go for it. Btw. we might think of using berlios.de - they offer a
>> SVN repository instead of CVS.
>
> 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:

Great :)

> This is probably going to change eventually, as one day we'll move to 
> Subversion (we actually have plans that are becoming concrete now, so 
> this WILL happen, just can't say when), and we also want to look into

Heh, same here. Aren't we version control laggards? :)


-- 
Christian Zagrodnick

gocept gmbh & co. kg · schalaunische strasse 6 · 06366 koethen
www.gocept.com · fon. +49 3496 3099112 · fax. +49 3496 3099118


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2355 bytes
Desc: not available
Url : http://lists.infrae.com/pipermail/silva-dev/attachments/20050419/30d521b6/attachment.bin