documancer-users — For users of Documancer

Re: [documancer] Documancer not running on Windows 98 SE

[aurelian <a.u...@gm...>]

Hi,

> yes, that's what I meant. Strictly speaking, the data should go into 
> C:\Documents and Settings\${username}\Application Data (obtained via 
> SHGetFolderPath) on NT/XP. Do you have any idea what is its 
> equivalent on 9x?

Under Windows 9x this would be C:\Windows\Application Data\${Appname}\. 
The folder name may be different for localized Windows versions (e.g. in 
German Windows versions it is "C:\WIndows\Anwendungsdaten\"). This 
applies to NT/XP too.

regards,
Johannes

Re: [documancer] Documancer not running on Windows 98 SE

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

Hi,

a.u...@gm... wrote:
> Maybe the best solution is to make it platform dependent - home
> directory under Linux and WinNT derivates, Installation directory
> under Windows 95 & derivates. How about that?

yes, that's what I meant. Strictly speaking, the data should go into=20
C:\Documents and Settings\${username}\Application Data (obtained via=20
SHGetFolderPath) on NT/XP. Do you have any idea what is its=20
equivalent on 9x?

Thanks,
Vaclav

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

Re: [documancer] Documancer not running on Windows 98 SE

[<a.u...@gm...>]

Hi,

> There aren't any other Win32 platforms, Win98 SE *is* Win95 platform. 
> My guess is that it works exactly as advertised in documentation -- 
> i.e. does nothing with the path because %HOME% is not set. Or is it?

You're right, %HOME% isn't set. I'll try setting it.

> No, it would not, C:\ is definitely *not* a good place for 
> configuration data! I don't know how to fix this properly, though. 
> Maybe pick app's directory as the data dir?

OK, didn't think about this long enough :-)
Yes, I also think the documancer app directory would be the best place. 

Under Windows (at least, 95 and 98), the home directory is the place for
documents, but not for configuration files. Also, files beginning with '.'
are not hidden and spam my home directory. :-) 

Maybe the best solution is to make it platform dependent - home
directory under Linux and WinNT derivates, Installation directory
under Windows 95 & derivates. How about that?

Regards,
Johannes Loehnert

-- 
+++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz

Re: [documancer] Documancer not running on Windows 98 SE

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

Hi,

a.u...@gm... wrote:
> It seems that os.path.expanduser only works correct under Win95/NT
> (see below).=20

There aren't any other Win32 platforms, Win98 SE *is* Win95 platform.=20
My guess is that it works exactly as advertised in documentation --=20
i.e. does nothing with the path because %HOME% is not set. Or is it?

> Maybe there is another trick to get the user home=20
> directory under 98SE. If not, replacing '~' by 'C:' should do.

No, it would not, C:\ is definitely *not* a good place for=20
configuration data! I don't know how to fix this properly, though.=20
Maybe pick app's directory as the data dir?

Regards,
Vaclav

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

[documancer] Documancer not running on Windows 98 SE

[<a.u...@gm...>]

Hello,

I recently tried to install Documancer 0.2.3 on a PC with Windows 98 SE.
Installation went O.K., but it wouldn't start up. After a bit of fiddling
around, I tracked it down to a 'bug' in the file "utils.py":

<code>
def getConfigDir():
    cdir = os.path.expanduser('~/.documancer/')
    if not os.path.isdir(cdir):
       os.mkdir(cdir)
    return cdir
</code>

os.path.expanduser doesn't work properly under Windows 98. After I replaced
the second line by the following,
<code>
    cdir = os.path.expanduser('C:/.documancer/')
</code>
the program started as it should.

It seems that os.path.expanduser only works correct under Win95/NT (see
below). Maybe there is another trick to get the user home directory under 98SE.
If not, replacing '~' by 'C:' should do.

Python help said the following:
 >>> help(os.path)
Help on module ntpath:

NAME
     ntpath - Common pathname manipulations, WindowsNT/95 version.
[...]

 >>> help(os.path.expanduser)
Help on function expanduser:

expanduser(path)
     Expand ~ and ~user constructs.

     If user or $HOME is unknown, do nothing.

Best regards,
Johannes Loehnert

-- 
+++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz

[documancer] mailing list available as news now

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

Hi,

I registered this list at Gmane mail<->news gateway (http://gmane.org)=20
so that people that prefer news can read it that way. The group is
    nntp://news.gmane.org/gmane.text.documancer
and there is (will be) an archive here:
    http://news.gmane.org/gmane.text.documancer

Regards,
Vaclav

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

Re: [documancer] Failed to lock the lock file

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

Hi,

Arnd Baecker wrote:
> if I am able to resolve
> this locally (which I have some doubts right now),
> the problem may in general occur for other users as well.

Yes, probably. I already modified Documancer to work even if locking=20
fails and I could move the lock file to $TMPDIR (which is almost=20
certainly not on NFS volume) after we fix wxSingleInstanceChecker to=20
not be vulterable to a DoS attack by another user if he can access=20
the lock file.

> BTW: wouldn't a normal file just serve the same purpose
> of saying "There is already a documancer instance running" ?
> (But presumably I am missing something ...)

There would be race condition related to writing and reading process=20
PID to/from the lock file.

Regards,
Vaclav

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

Re: [documancer] Failed to lock the lock file

[Arnd B. <arn...@we...>]

On Thu, 5 Feb 2004, Vaclav Slavik wrote:

[...]

> I have no idea what do it with it. Maybe try if a small C or Python
> app that uses advisory locks works (i.e. if it is specific to
> wxWindows).

Great - every time I have correspondence
with you I learn (or have to ;-) something new.
Alright, here we go:
The small python example below works fine on my local machine.
However, on the machine with the NFS mount stuff I get

  python lock_test.py
  Traceback (most recent call last):
    File "lock_test.py", line 26, in ?
      fcntl.flock(file.fileno(),fcntl.LOCK_SH)
  IOError: [Errno 37] No locks available

That looks pretty much like the message I got when
running documancer.
Well, I according to the sysadmin I thought locking is possible,
but maybe it is not or I am doing something wrong.

In any case I think that even if I am able to resolve
this locally (which I have some doubts right now),
the problem may in general occur for other users as well.

BTW: wouldn't a normal file just serve the same purpose
of saying "There is already a documancer instance running" ?
(But presumably I am missing something ...)

Best,

Arnd



######################################
"""
  If the lock_file exists: exit
  Otherwise: create lock_file and wait 10s.

  To test this: start this script and within the 10s try to start
                this again.

  According to the Python CookBook, 4.24, p. 152ff this
  is not cross-platform.
  (E.g. on Windows one has to use win32all)

"""

import os
import sys
import fcntl
import time

lock_file="test_lock_file.lock"

if os.path.exists(lock_file):
    print os.path.exists("test_lock_file.lock")
    print "Lock file exists - exiting"
    sys.exit(0)

file=open(lock_file,"w")
fcntl.flock(file.fileno(),fcntl.LOCK_SH)

print "Wait a while..."
time.sleep(10)

fcntl.flock(file.fileno(),fcntl.LOCK_UN)
file.close()
os.remove(lock_file)
################### EOF

Re: [documancer] Failed to lock the lock file

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

Hi,

Arnd Baecker wrote:
> # rpcinfo -p specific_machine_name | grep lock
> =A0 =A0 100021 =A0 =A01 =A0 udp =A032769 =A0nlockmgr
> =A0 =A0 100021 =A0 =A03 =A0 udp =A032769 =A0nlockmgr
> =A0 =A0 100021 =A0 =A04 =A0 udp =A032769 =A0nlockmgr
>
> Hope this helps you more than me ;-)

No :(

> If you need further input/tests etc. just let me know.

I have no idea what do it with it. Maybe try if a small C or Python=20
app that uses advisory locks works (i.e. if it is specific to=20
wxWindows).

Vaclav

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

Re: [documancer] Failed to lock the lock file

[Arnd B. <arn...@we...>]

On Thu, 5 Feb 2004, Vaclav Slavik wrote:

[...]
> > What would be the precise question to ask the system administrator
> > (or the system itself)?
>
> Whether the NFS server supports advisory locks on files or not, I
> guess.

Ok, he told me that it should:

# rpcinfo -p specific_machine_name | grep lock
    100021    1   udp  32769  nlockmgr
    100021    3   udp  32769  nlockmgr
    100021    4   udp  32769  nlockmgr

Hope this helps you more than me ;-)
If you need further input/tests etc. just let me know.

Many thanks,

Arnd

Re: [documancer] Failed to lock the lock file

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

Hi,

Arnd Baecker wrote:
> After "OK" for the "Failed to lock the lock file" window,
> another pops up with the message "Another Documancer instance
> is running, exiting." and on the command line the
> final words are "OnInit returned FALSE, exiting...".

That's a bug in my app, I should use Create() and check if it=20
succeeded.

> What would be the precise question to ask the system administrator
> (or the system itself)?

Whether the NFS server supports advisory locks on files or not, I=20
guess.

Vaclav

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

Re: [documancer] Failed to lock the lock file

[Arnd B. <arn...@we...>]

On Thu, 5 Feb 2004, Vaclav Slavik wrote:

> Hi,
>
> [I'm CC'ing this to wx-users because it's a wxWindows question and
> hopefully somebody will be able to give better answer than me]
>
> arn...@we... wrote:
> > I managed to compile
> > Python/wxPython/mozilla/wxMozilla/swish-e/documancer on a SUSE
> > Athlon based machine in our PC-Pool.
> > Everything looks pretty fine, however, when trying to start
> > documancer I get:
> >   "Failed to lock the lock file
> >   '/home/baecker/.documancer/documancer-baecker'
> >   (error 37: Keine Sperren verfuegbar)
> > ((I think this error 37 should roughly translate to "no locks
> > available" - hmm, internationalization can be a pain ;-)).
>
> And does it continue running after that? Failure to make the lock is
> not fatal for Documancer (you only risk some damage if running two
> instances of the app at the same time by the same user).

After "OK" for the "Failed to lock the lock file" window,
another pops up with the message "Another Documancer instance
is running, exiting." and on the command line the
final words are "OnInit returned FALSE, exiting...".

> > I have no idea why this happens (the .documancer directory
> > is created and also writable by the user).
> > If it is of any importance here: the home-directories
> > are NFS mounted and the access can be pretty slow sometimes.
>
> Yes, it is, locking may not work over NFS. First thing to check is if
> your wxWindows' copy setup.h has HAVE_FCNTL defined.

In
  /opt/python/wxWindows/lib/wx/include/gtk-2.4/wx/setup.h
I found
# define HAVE_FCNTL 1

> If not, then it
> won't work (see man flock). The same (Linux) manpage says that
> fcntl() does work over NFS, "given a sufficiently recent version of
> Linux and a server which supports locking."

This is sufficiently vague ;-) -
I think it is SUSE 8.1 (the kernel is 2.4.21), but
this doesn't really specify how recent the Linux is.
I don't know about the server.
What would be the precise question to ask the system administrator
(or the system itself)?

> I could create the lock file in $TMPDIR instead of in $HOME, but I
> don't what what the current best practise is, security-wise.

Maybe one could do this in case the "normal" variant fails.

Regards,

Arnd

Re: [documancer] Failed to lock the lock file

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

Hi,

[I'm CC'ing this to wx-users because it's a wxWindows question and=20
hopefully somebody will be able to give better answer than me]

arn...@we... wrote:
> I managed to compile
> Python/wxPython/mozilla/wxMozilla/swish-e/documancer on a SUSE
> Athlon based machine in our PC-Pool.
> Everything looks pretty fine, however, when trying to start
> documancer I get:
>   "Failed to lock the lock file
>   '/home/baecker/.documancer/documancer-baecker'
>   (error 37: Keine Sperren verfuegbar)
> ((I think this error 37 should roughly translate to "no locks
> available" - hmm, internationalization can be a pain ;-)).

And does it continue running after that? Failure to make the lock is=20
not fatal for Documancer (you only risk some damage if running two=20
instances of the app at the same time by the same user).=20

> I have no idea why this happens (the .documancer directory
> is created and also writable by the user).
> If it is of any importance here: the home-directories
> are NFS mounted and the access can be pretty slow sometimes.

Yes, it is, locking may not work over NFS. First thing to check is if=20
your wxWindows' copy setup.h has HAVE_FCNTL defined. If not, then it=20
won't work (see man flock). The same (Linux) manpage says that=20
fcntl() does work over NFS, "given a sufficiently recent version of=20
Linux and a server which supports locking."

I could create the lock file in $TMPDIR instead of in $HOME, but I=20
don't what what the current best practise is, security-wise.

Regards,
Vaclav

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

[documancer] Failed to lock the lock file

[<arn...@we...>]

Hi,

I managed to compile Python/wxPython/mozilla/wxMozilla/swish-e/documancer
on a SUSE Athlon based machine in our PC-Pool.
Everything looks pretty fine, however, when trying to start
documancer I get:
  "Failed to lock the lock file
  '/home/baecker/.documancer/documancer-baecker'
  (error 37: Keine Sperren verfuegbar)
((I think this error 37 should roughly translate to "no locks available"
 - hmm, internationalization can be a pain ;-)).

I have no idea why this happens (the .documancer directory
is created and also writable by the user).
If it is of any importance here: the home-directories
are NFS mounted and the access can be pretty slow sometimes.

What should I do to track this down ?

Best wishes,

Arnd

Re: [documancer] disable wxmozilla download window, solution

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

Hi,

arn...@we... wrote:
> user_pref("browser.downloadmanager.behavior", 1);

CVS copy of Documancer now (modulo SF.net's slowness) sets this on=20
startup (requires CVS version of wxMozilla).

Vaclav

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

Re: [documancer] broken pipe problem

[<arn...@we...>]

[...]
> > with the following I can produce a broken pipe
> > (see the traceback at the end):
> >   - Book: Python 2.3 Docs
> >   - Search String: AF_UNIX
> >   - Results:
> >     a) 1000 socket
> >     b)  889 7.2.1 Socket Objects
> >     c)  889 Index
> >     d)  873 11.15 SocketServer
> >   - wait until page a) is displayed
> >   - click on d), wait until it is displayed, everything is ok
> >   - click on c), do _not_ wait until it is displayed (it takes
> >     a little while because it is a long text)
> >     and click e.g. on a) ==> "broken pipe"
>
> This is harmless (the exception is catched, it only polutes stderr),
> but thanks anyway ;) It's now fixed, Documancer's HTTP server now
> handles all (HTTP) errors silently.

I am not quite sure if it is harmless - at least doing
this ("clicking on a search result before it is displayed")
a couple of times  I have the effect that documancer
does not react on clicks in the search results list
or on changing a book.
(Sorry, I should have added this description after the "broken pipe"
in the first place...)

> are there any  other characters that can be part of identifier?

Hmm, maybe this depends on the context, what about "-"?
(but I haven't really thought about this. I think
one could leave it as is at the moment and change
the behaviour once users complain. If it really
should turn out to be dependent on the documents
which are searched one could think of adding this as a configuration
option for the corresponding book. But at this point
that would be featurism IMHO ...;-)

> Note that you have
> to reindex the book for the fix to kick in.

Works perfect - many thanks.

> > - Even type-ahead find works to some extent,
> >   presently only for the text of links (!?).
> >   Do you think this is just a wxMozilla configuration issue ?
>
> Yes, it is -- set "accessibility.typeaheadfind.linksonly" to "false"
> in prefs.js.

Great, this works fantastic, many thanks.

Best, Arnd

Re: [documancer] broken pipe problem

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

Hi,

arn...@we... wrote:
> with the following I can produce a broken pipe
> (see the traceback at the end):
>   - Book: Python 2.3 Docs
>   - Search String: AF_UNIX
>   - Results:
>     a) 1000 socket
>     b)  889 7.2.1 Socket Objects
>     c)  889 Index
>     d)  873 11.15 SocketServer
>   - wait until page a) is displayed
>   - click on d), wait until it is displayed, everything is ok
>   - click on c), do _not_ wait until it is displayed (it takes
>     a little while because it is a long text)
>     and click e.g. on a) =3D=3D> "broken pipe"

This is harmless (the exception is catched, it only polutes stderr),=20
but thanks anyway ;) It's now fixed, Documancer's HTTP server now=20
handles all (HTTP) errors silently.

> Two more things:
> - For b) there seems to be no AF_UNIX in the text (at least none is
>   highlighted) ?!

Thanks! This was because SWISH-E treats _ as word deliminer. I fixed=20
this by adding _ and ~ to the list of word characters, are there any=20
other characters that can be part of identifier? Note that you have=20
to reindex the book for the fix to kick in.

>   ((BTW: do you think it is easy to enable a CTRL-f search
>     in the presently visible document ?))

=46rankly, I don't know because I didn't look into it yet. I _think_=20
there's something like that in wxMozilla, but I use type-ahead all=20
the time myself.

> - Even type-ahead find works to some extent,
>   presently only for the text of links (!?).
>   Do you think this is just a wxMozilla configuration issue ?

Yes, it is -- set "accessibility.typeaheadfind.linksonly" to "false"=20
in prefs.js.

Regards,
Vaclav

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

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

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

ba...@ph... wrote:
> =A0 <SEARCH>::<book_identifier_no_or_string>::<search_text>
> would allow for generalizations to other commands,
> such as previous/next hit and succh)
> The other option I can think of is to send the above as separate
> lines SEARCH
> =A0 <book_identifier_no_or_string>
> =A0 <search_text>

I prefer the latter because it doesn't involve any additonal parsing=20
=2D- for example, you don't have to worry about search requests or book=20
names that contain "::"...

VS

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

Re: [documancer] disable wxmozilla download window, solution

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

arn...@we... wrote:
> I.e. with this setting there is no download window
> left over after clicking on a pdf or ps document.

Thanks. I'll make Documancer set this flag on startup as soon as=20
wxMozilla supports that.

Vaclav

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

[documancer] broken pipe problem

[<arn...@we...>]

Hi,

with the following I can produce a broken pipe
(see the traceback at the end):
  - Book: Python 2.3 Docs
  - Search String: AF_UNIX
  - Results:
    a) 1000 socket
    b)  889 7.2.1 Socket Objects
    c)  889 Index
    d)  873 11.15 SocketServer
  - wait until page a) is displayed
  - click on d), wait until it is displayed, everything is ok
  - click on c), do _not_ wait until it is displayed (it takes
    a little while because it is a long text)
    and click e.g. on a) ==> "broken pipe"

Two more things:
- For b) there seems to be no AF_UNIX in the text (at least none is
  highlighted) ?!
  ((BTW: do you think it is easy to enable a CTRL-f search
    in the presently visible document ?))
- Even type-ahead find works to some extent,
  presently only for the text of links (!?).
  Do you think this is just a wxMozilla configuration issue ?

Best regards,

Arnd


----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 33645)
Traceback (most recent call last):
  File "/home/python/PYTHON_TST/lib/python2.3/SocketServer.py", line 222,
in handle_request
    self.process_request(request, client_address)
  File "/home/python/PYTHON_TST/lib/python2.3/SocketServer.py", line 241,
in process_request
    self.finish_request(request, client_address)
  File "/home/python/PYTHON_TST/lib/python2.3/SocketServer.py", line 254,
in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/python/PYTHON_TST/lib/python2.3/SocketServer.py", line 521,
in __init__
    self.handle()
  File "/home/python/PYTHON_TST/lib/python2.3/BaseHTTPServer.py", line
324, in handle
    self.handle_one_request()
  File "/home/python/PYTHON_TST/lib/python2.3/BaseHTTPServer.py", line
318, in handle_one_request
    method()
  File "/home/python/PYTHON_TST/lib/documancer/server.py", line 105, in
do_GET
    self.send_document(data, mime)
  File "/home/python/PYTHON_TST/lib/documancer/server.py", line 61, in
send_document
    self.send_response(200)
  File "/home/python/PYTHON_TST/lib/python2.3/BaseHTTPServer.py", line
377, in send_response
    self.send_header('Server', self.version_string())
  File "/home/python/PYTHON_TST/lib/python2.3/BaseHTTPServer.py", line
383, in send_header
    self.wfile.write("%s: %s\r\n" % (keyword, value))
  File "/home/python/PYTHON_TST/lib/python2.3/socket.py", line 254, in
write
    self.flush()
  File "/home/python/PYTHON_TST/lib/python2.3/socket.py", line 241, in
flush
    self._sock.sendall(buffer)
error: (32, 'Broken pipe')
----------------------------------------

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

[<ba...@ph...>]

Hi,

> > That sounds good. So the "search string" sent to documancer-remote
> > could look like
> >   <book_identifier_no_or_string>::<search_text>
>
> Why not e.g.
>   documancer-remote --book="Python" --search="thread and lock"
> ? Saves parsing... And there may be other remote commands other than
> search that take book argument.

Absolutely! In my remark above I messed up the options
given to documancer-remote and what documancer-remote will send
to the file socket (i.e. to the documancer application).
What I wanted to express is that one presumably
needs to specify some "protocol" of commands send back and forth
between eg. documancer-remote and the documancer application.
Putting everything in one string may have the advantage that
all needed information arrives in one chunk, however parsing of this
line is required. (Actually something like
  <SEARCH>::<book_identifier_no_or_string>::<search_text>
would allow for generalizations to other commands,
such as previous/next hit and succh)
The other option I can think of is to send the above as separate lines
  SEARCH
  <book_identifier_no_or_string>
  <search_text>
which have to be combined by the documancer application
before the required task can be performed.
Presumably there is a much better way than this ...

Anyway, the next three weeks I am 100% busy with other stuff ...

Best regards,

Arnd

[documancer] disable wxmozilla download window, solution

[<arn...@we...>]

Hi,

I had another look at the preferences for wxmozilla,
and with the below prefs.js (which is
in the directory ~/.documancer/mozilla-profile)
it works for me (presumably it's best to
edit that file when documancer is not running).
I.e. with this setting there is no download window
left over after clicking on a pdf or ps document.

Best,

Arnd


## prefs.js  <----- cut here ---->
# Mozilla User Preferences

/* Do not edit this file.
 *
 * If you make changes to this file while the browser is running,
 * the changes will be overwritten when the browser exits.
 *
 * To make a manual change to preferences, you can visit the URL
about:config
 * For more information, see
http://www.mozilla.org/unix/customizing.html#prefs
 */


user_pref("browser.downloadmanager.behavior", 1);

## EOF prefs.js

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

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

Hi,

arn...@we... wrote:
> Alright, that sounds much better, but I don't have any
> experience in this direction ...
> On my unix box a
>   sock=3Dsocket.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* ;-)...

It (almost) certainly doesn't, but it's better to have it working on=20
Unix  than not at all and win32 mechanism can be added later...

> That sounds good. So the "search string" sent to documancer-remote
> could look like
>   <book_identifier_no_or_string>::<search_text>

Why not e.g.=20
  documancer-remote --book=3D"Python" --search=3D"thread and lock"
? Saves parsing... And there may be other remote commands other than=20
search that take book argument.

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

The books are internally identified by their name, so this is not a=20
problem. The ID is identical to the (human-readable) title of the=20
book.=20

> More generally, for searches (both remotely and within documancer)
> a way to specify collection of books would be nice.

Yes, by all means.

Regards,
VS

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

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

[<arn...@we...>]

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

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/