[rrd-developers] implementing portable format

[Sebastian Harl]

Hi Kevin,

On Mon, Nov 03, 2008 at 07:39:02AM -0600, kevin brintnall wrote:
> On Sun, Nov 02, 2008 at 12:42:13PM +0100, Sebastian Harl wrote:
> >   * Add a new command BATCH_FINISH (or something like that) that tells
> >     the daemon that the current job is finished. Now, the client will
> >     block until all commands are done and the return code / values are
> >     available.
> 
> All commands are executed when received.  I don't see a reason to change
> that since the command execution part is very fast.

I don't want to change that. The point of introducing BATCH_FINISH is to
delay sending back status codes (in one block) until the batch job (i.e.
all submitted commands) is finished to be able to know when it's done
and, optionally, what individual status codes have been returned.

So, this is very similar to "." in your implementation but with a dif-
ferent behavior regarding the return values.

> BATCH mode implies success.  It only returns messages in case of error.
> This reduces the amount of server->client communication that's required.

... and breaks the protocol which expects (used to expect) that at least
one line would be returned. Also, status codes are now very inconsistent
in that values >= 0 no longer indicate success.

This is, in fact, my biggest concern.

> >     - BATCH_* returns a handle identifying the command. BATCH_FINISH
> >       then returns the appropriate handle followed by the return values
> >       of the command. This happens for one command at a time in random
> >       order (presumably the order in which the commands have been
> >       finished). The daemon needs to cache those return values until
> >       they can be sent to the client. A special handle might be used to
> >       indicate the end of return values.
> 
> You may as well just return the result code directly in this case, instead
> of a handle.

Oh right, that won't work without breaking BATCH mode. Sorry for over-
looking that part. However, my alternate proposal should still work
(i.e. returning the status codes in the same order the commands have
been issued, skipping those marked 'uninteresting') ...

Anyway, I don't really have a _really_ strong opinion on that (besides
the inconsistent protocol issue). I would have probably implemented that
differently but I don't currently have the time to write and send in any
patches so I'll shut up and stop discussing this issue. I just hope my
intention has become clear ;-)

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20081105/26583388/attachment.bin