hglib: 'connect' feature

[Idan Kamara]

On Fri, Dec 30, 2011 at 12:20 PM, Andrey <py4fun at gmail.com> wrote:

> Hi Idan,
> since I misuse the mailing list I would like to send the reply to your
> private e-mail.
>

Sure. I cc-ed the list again so we can continue the discussion there after
you follow the instructions below.


> By the way, if it does not bother you, can you please help me to find out
> what is the 'normal' way ? Unfortunately I cannot use standard e-mail
> client (like Thunderbird) because POP and IMAP protocols are forbidden at
> my place. Firewall does not allow chatting either...
>

You should subscribe to the mailing list directly rather than using a web
interface (like Google Groups) to send the emails for you.

There's no need for any special software, you just have to go here
http://www.selenic.com/mailman/listinfo/mercurial-devel/ and sign up.
Then you'll receive emails directly to the email you registered with and
you can reply to the messages the 'normal' way.


> Back to the point.
>
> My idea is to move the 'connect' argument to the factory methods. Then
> users may decide whether they need to launch 'hg serve --cmdserver pipe' or
> not.
>

Not sure I like having the return value be dependent on an argument to the
function.

Regardless, I think this is less convenient in terms of API. You have to
decide at the point of calling these two functions if you want to connect
or not.
The current approach doesn't limit you, you get back a client object which
you can later use if you wish to connect.


>
> This is how it will look like:
>
> r = hglib.init(..., connect=True)
> hglib.init(..., connect=False)  # this returns None
>
> r = hglib.clone(..., connect=True)
> hglib.clone(..., connect=False)  # this returns None
>
> But if you have an instance of hgclient you can be sure it is connected.
> No need to call 'open'.
>

I see you're bothered by the possibility of having client objects that
aren't connected.
I'm not sure this is really an issue (also this was possible before by
explicitly calling close() on the client). Why do you think this is a
problem?


>
> Andrey
>
>
>> That is one possibility.
>> The upside of the current approach is that it lets you do:
>>
>>     r = hglib.clone(...).open()
>>
>> (but also with the possibility of not connecting)
>> vs
>>
>>     hglib.clone(...)
>>     r = hglib.open(...)
>>
>> Not much of a difference, but more convenient I guess.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111230/ed8934f0/attachment.html>