Hi again,
> Asger> You could do a hack: Send a command to LyX that has no ill
> Asger> side-effects, but returns something (like where the cursor is),
> Asger> and if you get the result immediately, you know that the
> Asger> previous command succeeded. Actually, this trick could spare
> Asger> us from modifying the protocol.
>
> It is a bit stupid IMO that no info is returned after a successful
> command... I'd rather see a command to enable feedback.
<snip>
> Concerning the return of function values, nothing in the protocal
> states that a message is returned only if the function has a
> result. Even an error will be unnoticed if there is not error message
> (which is not possible now).
What I gathered upon first reading of the Lyx Server chapter in the
customization docs was indeed that a message was always issued to notify
clients. From that document:
VVVV
"The answer from LyX will arrive in the output pipe and be of the form
INFO:clientname:function:data
where clientname and function are just echoed from the command request,
while data is more or less useful information filled according to
how the command execution worked out. Some commands will return
information about the internal state of LyX, such as ``font-state'', while
other will return an empty data-response. This means that the command
execution went fine."
So I understood that an INFO message was alwyas issued on success, and
that the only difference for functions returning nothing was an empty
"data" field in the reply.
> I propose that we change the protocol now. I suspect that few
> applications listen to the pipe anyway. A possibility would be to send
> a LYXSRV:client:verbose to set the right flag on. It seems to me to be
> the simplest way of doing it. The client could listen to the pipe to
> see whether this command is implemented by the protocol (whether it
> receives the same string).
It seems that if there is no existing application listening to the output
pipe, even sending messages always wouldn't do any harm, but I do know
only about the two bibtex-helper applications mentioned by Asger (they
never read from .lyxpipe.out, if I understand their code).
>
> What do you think?
>
I still think that being able to read a line from the output pipe
after each command would be reassuring for client programs, and also
simpler to implement with respect to select(2) tricks or the
harmless-command mechanism suggested by Asger. It will also encourage
client developers to actually check for errors, since clients would be
able to treat in the same way functions wanting data back or no data back,
just send-a-line, get-a-line in every case, then check for INFO or ERROR.
Only my thoughts,
Stefano
Stefano Ghirlanda, Zoologiska Institutionen, Stockholms Universitet
Office: D554, Arrheniusv. 14, S-106 91 Stockholm, Sweden
Phone: +46 8 164055, Fax: +46 8 167715, Email: [EMAIL PROTECTED]
Support Free Science, look at: http://rerumnatura.zool.su.se
