Re: [documancer] Re: a few bugs?

arnd.baecker-S0/[email protected] Mon, 5 Jan 2004 11:01:15 +0100 (CET)
Newsgroups gmane.text.documancer.user
Message-ID <[email protected]>
Hi,

On Sat, 27 Dec 2003, Vaclav Slavik wrote:
[...]
> 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).

Alright, that sounds much better, but I don't have any
experience in this direction ...
On my unix box a
  sock=socket.socket(socket.AF_UNIX,socket.SOCK_STREAM)
  sock.bind("socket_file")
works fine. I don't know if this works under windows as well,
but I am skeptical (AF_*UNIX* ;-)...

> 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.

That sounds good. So the "search string" sent to documancer-remote
could look like
  <book_identifier_no_or_string>::<search_text>
((I think a textual identifier for the book would be better
than a numerical id (unless this is "uniquely" attached to
a book string) so that re-ordering/additions of books does
change the association)).

More generally, for searches (both remotely and within documancer)
a way to specify collection of books would be nice.
On the level of config.ini they could look like
  [Collection/Title_of_collection_1]
  title=Title of collection 1
  books=Book_1:Book_2:Book_3

On the GUI side one would need a small collection manager
(I think a wxCheckBox or wxCheckListBox would be nice for that).
If one removes a  book are removed one has to take care to remove
it  from any collection in which it shows up as well
(and possibly remove a collection if it contains no elements anymore).

Best,

Arnd


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click