incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.jaqu...@mac.com>
Subject Re: JSPWiki 3 design notes
Date Wed, 13 Feb 2008 18:02:06 GMT
There are a bunch of considerations here...

The biggest pain point, I suspect is that all of the pages need to be  
examined at startup time. That's an expensive operation. Similar to  
how we run the Lucene indexer in a background thread, an easy way to  
speed up startup would be to initialize the ReferenceManager that way,  
too.

However, that's probably not the whole answer. It seems to me that  
references (what links to Page X, and what does Page X link to) is  
also something that should properly be stored as page metadata. So,  
that's probably part of the solution too. Certainly, part of the plan  
would be to enable deployers to share page repositories, and  
references would be part of that.

That's just my $0.02. I am not the author of ReferenceManager, and am  
not too familiar with the code (although I've hacked it slightly to  
get it working with my 3.0 branch).

Andrew


On Feb 13, 2008, at 12:32 PM, Harry Metske wrote:

> I am not sure if this question is at the right place here, but will  
> it be
> possible to make JSPWiki more scalable with this new design ?
> And then I mean running multiple instances (JVM's) of JSPWiki  
> against 1
> shared repository.
>
> The current version of JSPWiki does not offer that scalability, for  
> instance
> because of the referencemanager, at least not with a File based  
> repository.
> Running a wiki with hundreds of thousand or even million pages would  
> (I
> guess) not be possible right now. Startup times would take too long
> probably.
>
> regards,
> Harry Metske
>
>
> 2008/2/7, Janne Jalkanen <Janne.Jalkanen@ecyrd.com>:
>>
>>> Wow. That sounds pretty damn useful for JSPWiki and beyond. I shared
>>> Murray's concern about total dependence on JCR too, but if a
>>> light-weight file-based JCR implementation is feasible, that
>>> definitely changes my thinking.
>>
>> Yes, it is very feasible - as long as you don't try to shoot for
>> total JSR-170 compliance.  Some things, like XPath queries or SQL
>> queries can be a bit too complicated, though.  But if we keep the
>> feature set that we need relatively clean, and upgrade gradually,
>> then I think it all should work just nicely.
>>
>> /Janne
>>
>
>
>
> -- 
> met vriendelijke groet,
> Harry Metske
> Telnr. +31-548-512395
> Mobile +31-6-51898081


Mime
View raw message