All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pirate Praveen <praveen@debian.org>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Cc: git@vger.kernel.org
Subject: Re: support git+mosh for unreliable connections
Date: Mon, 20 Apr 2015 14:09:57 +0530	[thread overview]
Message-ID: <5534BB5D.4000802@debian.org> (raw)
In-Reply-To: <20150415202647.GA29170@LK-Perkele-VII>

[-- Attachment #1: Type: text/plain, Size: 1608 bytes --]

On Thursday 16 April 2015 01:56 AM, Ilari Liusvaara wrote:
> On Wed, Apr 15, 2015 at 08:13:51PM +0530, Pirate Praveen wrote:
>>
>> Q: Are the mosh principles relevant to other network applications?
>>
>>     We think so. The design principles that Mosh stands for are
>> conservative: warning the user if the state being displayed is out of
>> date, serializing and checkpointing all transactions so that if there
>> are no warnings, the user knows every prior transaction has succeeded,
>> and handling expected events (like roaming from one WiFi network to
>> another) gracefully.
>>
>> Can the ideas be used to resume a pull, push or clone operation?
>> Especially serializing and checkpointing.
> 
> Well, it is possible to write a remote helper and serverside program
> that internally handles connection unreliability, so Git itself
> (upload-archive, upload-pack, receive-pack, archive, fetch-pack
> and send-pack) sees a reliable (full-duplex, half-closeable, stream)
> channel.
> 
> Suitably done, that can "resume" (from Git POV, nothing special
> happened) across things like IP address changes.
> 
> However, that is quite difficult to do in practice. Not because
> interface to Git is complicated, but because the transport problem
> itself is complicated (however, it still seems way easier than
> making Git internally be able to resume interrupted operations).
> 
> Mosh needs to solve at least most of that, it just doesn't provode
> the right kind of interface.

I have requested mosh team to fix these issues
https://github.com/keithw/mosh/issues/597



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

      reply	other threads:[~2015-04-20  8:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-15 13:07 support git+mosh for unreliable connections Pirate Praveen
2015-04-15 13:45 ` Dennis Kaarsemaker
2015-04-15 13:52 ` Michael J Gruber
2015-04-15 14:18   ` Pirate Praveen
2015-04-15 14:41     ` Johannes Schindelin
2015-04-15 15:33       ` Trevor Saunders
2015-04-15 17:46         ` Johannes Schindelin
2015-04-15 18:59           ` Trevor Saunders
2015-04-16  9:29             ` Michael J Gruber
2015-04-15 19:25           ` Dennis Kaarsemaker
2015-04-22  6:54             ` Andreas Krey
2015-04-15 14:22 ` Johannes Schindelin
2015-04-15 14:43   ` Pirate Praveen
2015-04-15 20:26     ` Ilari Liusvaara
2015-04-20  8:39       ` Pirate Praveen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5534BB5D.4000802@debian.org \
    --to=praveen@debian.org \
    --cc=git@vger.kernel.org \
    --cc=ilari.liusvaara@elisanet.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.