Re: [documancer] Re: [documancer-users] a few bugs?

[Vaclav S. <vac...@ma...>]

Hi,

arn...@we... wrote:
> Hmm, I really don't like it so I will have a closer look at
> that=20

Thanks!

> That looks nice - also checked it here: same happens ....
> (BTW: maybe it is problematic to link the mozilla configuration
> from ~/.mozilla to the one from documancer as suggested in the FAQ
> as changes on the documancer side reflect back to the "normal"
> mozilla (which might be even a different version) ...)

Yes, it almost certainly is and will get more dangerous when I add=20
font configuration etc., I'll correct the FAQ.

> > >   Therefore it would be nice to have the search indices
> > >   for these documents just generated once (by "root")
> > >   so that the users to not have to create and store
> > >   their own copy of this.
> >
> > Yes... It opens some problems, though:
> > * How do you edit global vs. root-user-only books?
>
> sorry, I don't understand the question -  what do
> you mean by "global" books ?

The ones shared by all users, i.e. installed in /var/lib/documancer=20
(or whatever) instead of ~/.documancer.

> Hmm, maybe this is asking too much: the program could just say:
> "sorry, I cannot update the index, please ask root to do it...".

That's way too annoying.

> Optionally it could offer to create a local index
> (which gets removed if there is an updated global one ??)

OTOH, this makes sense.

> Generally I would think that documentation on the root
> level will not change that often ...

I can see one case when it can happen quite frequently: when -devel=20
packages with documentation are upgraded on Linux.

> By now I had a look at swish-e and actually
> one can tell it to index pdf files
> (or anything else) by providing the appropriate filters.
>
> I tried the prog variant (i.e. example9.config from
> the swish-e examples), however I ended up with
> "Warning: XML parse error in file".
> In contrast  example8.config, which uses a filter,
> _pdf2html.pl and the xpdf package , works fine!
> ((The call is just
> swish-e  -c example8.config -v 3  -f index.swish-e
> /directory_with_html_and_pdf/
> ))
> In contrast the call
> swish-e -v 3  -f index.swish-e -i    /directory_with_html_and_pdf/
> will also index the pdf files, but "raw", i.e. without
> conversion to html or xml, producing useless index entries.
> If you want I can look further into this
> so that one could add this to the configuration file
> written indexer.py.

Maybe it would suffice if we provide PDF-enabled config file with=20
Documancer? Even though I think this level of PDF support is not good=20
enough to be proud of it, I certainly won't stay in the way of having=20
at least some support!

> Alright, I also looked into this a bit - I have set up a small
> example which communicates via sockets
> To incorporate this into documancer the approach could be the
> following - app.py: DocumancerApp(wxApp):
>     def OnInit(self):
>         [....]
>         docuServer.runDocuServer(inBackground=3D1,DoSearch)
>
>    # - here DoSearch is defined in MainFrame.py
>    # Question: should one use the uiCallback for making
>    #           this available here ?

I don't understand the question.

> Now any external programm which wants to send a search string
> needs to know the address of the "docu server"
> (determined analogously to getServerPort (from utils.py)).
> Should one store that number in a file in the ~/.documancer
> directory?

I think it will be much better to use Unix domain sockets instead.=20
It's more secure (if the permissions on socket are correct, only the=20
user who runs documancer can access it) and it doesn't have the=20
problem of finding the port number (the socket is in filesystem in=20
predermined location, e.g. ~/.documancer/socket-remote-control).=20
Win32 has some IPC mechanism that can be used instead (but it, sadly,=20
isn't wrapper by wxPython). I'd like to eventually get rid of having=20
to run HTTP server at all, for security reasons, but I need protocol=20
handlers support in wxMozilla for that first (it's on the way).

What I had in mind was a remote control server thread running in=20
Documancer (as you did it) plus a small documancer-remote program,=20
preferably written in C so that it has very little startup overhead=20
and new instance of it can be launched for every request (so that =20
you can simply bind a shortcut in Vim to launching specific=20
documancer-remote command and get instant response). This small=20
program would do no real job, it would only route requests to=20
Documancer server (it wouldn't even have to parse its command line,=20
it could send it as-is) and to launch Documancer if no instance is=20
running yet.

> Hmm, there is one missing bit in the above approach:
> in some way we need to specify the book in which the search should
> be done ...
> (so maybe the external program needs to parse
> ~/.documancer/config.ini, and pre-pend this to the search string
> ?).

Ideally you should be able to run, say, "documancer-remote=20
=2D-list-books", which would be sent to the real Documancer and its=20
output would then go to stdout, w/o having to worry about parsing=20
config.ini in the remote controller.

> time). So at this point I better don't make any promises
> and just restrict myself to some kind of "testing".

=2E..which is *very* useful in itself! You're helping me a lot with=20
clever complains ;) and suggestions, so thanks for that!

Regards,
Vaclav

=2D-=20
PGP key: 0x465264C9, available from http://pgp.mit.edu/