> >-> cache pages so often visited pages will be pushed from the
> > static cache
>
> I don't really get it here. Isn't this feature available already ?
>
This is already implemented. The pages are buffered and then saved in $LANG
dir.
You must configure with --enable-content-caching=yes
Gabor Hojtsy wrote:
I am not really talking about this in connection with the visual editing
part. Livedocs was developed initially to fulfill this need. A translator
needed to wait a lot of time to get a new generated version of the XML...
A lot of people are unable to imagine how that XML will l
> >I am not really talking about this in connection with the visual editing
> >part. Livedocs was developed initially to fulfill this need. A translator
> >needed to wait a lot of time to get a new generated version of the XML...
> >A lot of people are unable to imagine how that XML will look like
Gabor Hojtsy wrote:
We have talked about some things on the linuxtag docmeeting about
developing plugins for it. This is only possible however if livedocs
allows plugins :) Separation of different parts is essential to enable
livedocs to handle plugins.
While we are talking about this. I ha
> > We have talked about some things on the linuxtag docmeeting about
> > developing plugins for it. This is only possible however if livedocs
> > allows plugins :) Separation of different parts is essential to enable
> > livedocs to handle plugins.
>
> While we are talking about this. I have think
Nuno Lopes wrote:
Hi didou,
I like the idea of the themes/skins. And the idea to split is even better...
I like your dir tree.
I agree with you that the search should be improved. The current is a bit
bogus..
A file with the explanation of the program should be great: the explanation
of the dir tr
Hi
Sorry for the delay but I was busy :/
Hi!
4 hours in the train, enough to dream...
Hehe :)
I've tried to imagine the best evolution for livedocs, and I've seen one
major modification needed : Separation
Actually, we have three main parts :
- Build
- XML parsing
- HTML rendering
When l
> >>4 hours in the train, enough to dream..
> >>I've tried to imagine the best evolution for livedocs, and I've seen one
> >>major modification needed : Separation
> >
> > Please make sure that you don't over design. It's supposed to be FAST.
>
> So everyone is supposed to hack its own copy ? I rea
Derick Rethans wrote:
On Tue, 20 Jan 2004, Mehdi Achour wrote:
4 hours in the train, enough to dream..
I've tried to imagine the best evolution for livedocs, and I've seen one
major modification needed : Separation
Please make sure that you don't over design. It's supposed to be FAST.
So everyo
On Tue, 20 Jan 2004, Mehdi Achour wrote:
> 4 hours in the train, enough to dream..
> I've tried to imagine the best evolution for livedocs, and I've seen one
> major modification needed : Separation
Please make sure that you don't over design. It's supposed to be FAST.
regards,
Derick
Hi!
> 4 hours in the train, enough to dream...
Hehe :)
> I've tried to imagine the best evolution for livedocs, and I've seen one
> major modification needed : Separation
>
> Actually, we have three main parts :
> - Build
> - XML parsing
> - HTML rendering
>
> When livedocs was available t
Hi didou,
I like the idea of the themes/skins. And the idea to split is even better...
I like your dir tree.
I agree with you that the search should be improved. The current is a bit
bogus..
A file with the explanation of the program should be great: the explanation
of the dir tree, the database
Hi folks !
4 hours in the train, enough to dream..
I've tried to imagine the best evolution for livedocs, and I've seen one
major modification needed : Separation
Actually, we have three main parts :
- Build
- XML parsing
- HTML rendering
When livedocs was available through CVS, I've checked
13 matches
Mail list logo
