Sketch the header for level 1

[Iulian Stana]

Hi,

2013/8/5 Giovanni Gherdovich <g.gherdovich at gmail.com>

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

I think that I cannot give a better explanation.

I agree that some calls could run for a long period of time, but like
Giovanni said, I think that on level 1, the commands must be in a compact
form.
Probably I'm not seeing this issue, from the best view point. If you really
want to process your data when you receive them, you can use level 0 to
build such kind of function.

>From what I understand from your mail, you would like to do something like:

hg_log( ... ); /* Get the entire log history. Normally this call will take,
5 minutes.*/
/* You don't want to wait 5 minutes.*/
/* Start processing the log data, after 1 millisecond.*/
/* Continuing your work. */

>From my knowledge, a user can put the log command in a thread. I
don't know and I don't think that is't my job to make this processes.
I am not sure about my thoughts, please correct me.

-- 
Iulian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130805/4754c727/attachment.html>