Sketch the header for level 1

Giovanni Gherdovich g.gherdovich at gmail.com
Mon Aug 5 00:33:48 CDT 2013


Hello Kevin,

Kevin wrote:
:::: On 1 Aug 2013, at 6:18 AM, Iulian Stana wrote:
:::: >
:::: > 2) I think that the best solution for all those commands
:::: >    will be to return a structure of the following form:
:::: > struct hg_ret{
:::: >     int exitcode;
:::: >     char *out_data;
:::: >     char *err_data;
:::: > };
::::
:::: Again, for things like `hg log`, you'll want to be able to read the
output
:::: (and errors) long before you could possibly get the exit code.
::::
:::: I really think you need to nail down the full details of
:::: how level 0 will work before thinking about level 1.

Iulian and me long meditated over the IRC session
held on July 2nd where Matt explained how exit codes works:
http://bpaste.net/show/FW3tCYalMJIjNkgRwyOG/

line 28, "<mpm> You cannot return an exit code from hg_rawcommand."
line 50-51 "<mpm> iulians: Ok, let's say I do
            hg_rawcommand("this command will run for four days and output
500G of data")..
            when does this API call return?
            Can I convince you that the answer should not be
            "four days from now after trying to buffer 500G of data"?

Basically what we understood is that the level 0 function hg_rawcommand()
should just send the command, and a successfull return code would mean
"command sent w/o problems". Then you read the answer with as many
hg_rawread()s as you need, and finally call hg_exitcode().

But when moving on to level 1, a function like hg_log() would be all-in-one,
meaning it will be implemented like

int hg_log(...) {
    hg_rawcommand(...);
    while(hg_rawread(...)) {
        ...
    }
    return hg_exitcode(...);
}

which is, hg_log() *will* buffer data internally. Otherwise, as Idan notes
in his previous email in this thread, there is no added value in writing
level 1 at all; we just stick to level 0.

But Matt also writes, in the backlog above (line 32)

"<mpm> The client library cannot/should not
       internally buffer unknown huge masses of data."

which, at this point, confuses me.

I really hope we can have a discussion on IRC about this today.
It has been long since Iulian had some feedback from the seniors.

:::: I really think you need to nail down the full details of
:::: how level 0 will work before thinking about level 1.

Iulian did write implementation sketches for level 0, here:
http://markmail.org/thread/5i6xltisgr4x3ze
There one can find Patch 1/3 with the header,
Patch 2/3 with an implementation sketch of a few commands
by means of level 0 API (like `hg log`), and Patch 3/3 with an attempt to
implement the level 0 API.
Apart from error handling, which is missing, there is quite some
material there to review.

Might we ask you an eyeball?

Cheers,
Giovanni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130805/315b2e61/attachment.html>


More information about the Mercurial-devel mailing list