Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Sun, Jul 16, 2006 at 11:34:34AM +0200, Lars Gullik Bjønnes wrote:
| > | Apart from that I never said we should not use the LFUN interface.
| > | However, going through the lyxserver is a completely unecesary
| > | complication.
| >
| > So what communication channel do you see as suitable?
| > (Or do you want to run python/perl/ruby/C/whatever as part of the lyx
| > processs?)
|
| For external use a python extension seems to be in orderi. This could
| be just a thin wrapper around the lfun interface. [This is closer to
| 'embedding LyX in Python'.]
|
| This _could_ also use a LyX instance that's connected over a server
| pipe, but would be much simpler to put everything of LyX - main() in
| a lib and link to this lib.
|
How will this make anything easier?
I still need to have communication between two processes? Are you
moving on to shared memory now?
| For internal use, this python + extension could be embedded in LyX.
| Even if this sounds a bit more complicated conceptionally, it is
| actually simpler to implement because the 'lyx kernel lib' is not
| needed. It'll boild down to (rough estimation) 200 lines of glue code +
| linking with libpython.
|
| Without extra work his means that python runs indeed in the same process
| as LyX. However, I don't see a big problem there. We already link to
| half a dozen external libs and python seems rather stable to me. More
| stable than LyX itself, actually. And there might be other benefits
| as
But can we then easily take advantage over that stability? Or have we
just made everything harder since we know have external api's to
adhere to.
| reduced starup times for the conversion scripts or such.
Ok... then I have my nice little bibtool, written in python. How will
that commnunicate with LyX? Not at all? I have to start the tool from
inside LyX?
--
Lgb
