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

Hi,

arnd.baecker-S0/[email protected] wrote:
> Hmm, I really don't like it so I will have a closer look at
> that 

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 
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 
(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 
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 
Documancer? Even though I think this level of PDF support is not good 
enough to be proud of it, I certainly won't stay in the way of having 
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=1,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. 
It's more secure (if the permissions on socket are correct, only the 
user who runs documancer can access it) and it doesn't have the 
problem of finding the port number (the socket is in filesystem in 
predermined location, e.g. ~/.documancer/socket-remote-control). 
Win32 has some IPC mechanism that can be used instead (but it, sadly, 
isn't wrapper by wxPython). I'd like to eventually get rid of having 
to run HTTP server at all, for security reasons, but I need protocol 
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 
Documancer (as you did it) plus a small documancer-remote program, 
preferably written in C so that it has very little startup overhead 
and new instance of it can be launched for every request (so that  
you can simply bind a shortcut in Vim to launching specific 
documancer-remote command and get instant response). This small 
program would do no real job, it would only route requests to 
Documancer server (it wouldn't even have to parse its command line, 
it could send it as-is) and to launch Documancer if no instance is 
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 
--list-books", which would be sent to the real Documancer and its 
output would then go to stdout, w/o having to worry about parsing 
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".

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

Regards,
Vaclav

-- 
PGP key: 0x465264C9, available from http://pgp.mit.edu/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQA/7gTaxDYa/UZSZMkRApN/AJ9o2uQy28WIgeGvXFQ7BwnoR9Y12QCgprgf
5eJ75YU4pX9PaAAZ0ymD+6I=
=mNA/
-----END PGP SIGNATURE-----