luni, 9 septembrie 2013

#11 - C implementation of command server API

Using the approach that I mentioned in the last blog post I was able to finish
the implementation for all mercurial commands (the implementation for level 1).

The code has grown fast and now it’s time to start the refactoring to make it
clearer and easier to understand.

Also I have to create some automatic tests to make the API stronger and to proof
that you can use the code without any risks. Until now I tested the code into a
main function, using some system calls to create the repository and to test my
commands. The verification was just visual.

This is not enough to show the correctness but more ample tests will follow
soon.

luni, 2 septembrie 2013

#9-10 - C implementation of command server API

In the last two weeks, I focused on building a strong environment for level 1 of
hglib API. I exchanged communication with the interested peers to find the best
architecture and style that will fit with my project. We chatted a lot on the
IRC channel and I also got reviews on my patchbombs from dev-list.
In the end we decided to split this level in two, using two models to implement
the mercurial commands.
""""
There are two possibilities on how level 1 commands can behave:
(1) Return immediately after having sent the command to commandserv,  just
wrapping a call to hg_rawcommand().
   Other API functions are provided to retrieve:
   (a) the data sent in response by the commandserv, in parsed (structured) form
   (b) the exitcode, i.e. the content of the 'r' channel after all things  have
happened.
(2) Wait for the commandserv to complete *all* its actions in response to the
issued command, which is cached in the commandserv response somewhere, and
return the actual exitcode (channel 'r' from commandserv) as the result of the
chglib API call
"""
Using this idea I sketched those two models.
I associated the hg_log command to model 1, because this command will handle a
huge amount of data. In this way, the problem of overflowing my memory was
bypassed. Also for this model I implemented a mechanism that we called
iterator-like mechanism, from where the user will get some parsed data in a
predefined structure. In this way the user will get his desired data in a more
easier way.
For model 2 I sketched the hg_add command, because the add command and more
other mercurial commands, are not performing any kind of parse data. The most
important thing on those commands is the exitcode, even if everything works well
or not. Also we can have errors for those kind of commands, errors that some
users will be interested in. To give users the possibility to handle those
errors we use a callback function, created and passed by users to those
commands.
After sketching those two models, it was a short time where I was waiting to
receive review to know if the implementation is the waiting one. Meanwhile I
made a list with all mercurial commands to know with which of those what model
will fit.
Until now, I implemented a good part of mercurial commands but still have a lots
of work. Probably at the end of this week I will finish the implementation for
all mercurial commands and will start to make a big refactoring.