Sketch the header for level 1

Kevin Bullock kbullock+mercurial at ringworld.org
Mon Aug 5 22:53:44 CDT 2013


On 5 Aug 2013, at 12:33 AM, Giovanni Gherdovich wrote:

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

It shouldn't be that confusing; calling hg_log() shouldn't buffer data any more than calling hg_rawcommand("log", ...) should. The difference between the two calls is that hg_log() should return the results in a more structured form for programmatic manipulation (for example, a list of hash tables of commit attributes: ID, rev, user, date, description, ...; or a list of structs representing log entries; or whatever structure makes most sense).

> :::: 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?

Just sent some comments. Yes, I know there wasn't much response before to the level 0 sketch -- the thing to do would be to ping the interested parties, rather than plow ahead with work that will likely need significant (and obvious) changes based on the feedback to level 0.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock



More information about the Mercurial-devel mailing list