| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
| |
I'd rather Utility.Ssh, but the SshData type is not sufficiently clean and
generic for Utility.
|
| | |
|
| |
|
|
| |
Has a button to cancel the request.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
They work fine. But I had to go to a lot of trouble to get Yesod to render
routes in a pure function. It may instead make more sense to have each
alert have an assocated IO action, and a single route that runs the IO
action of a given alert id. I just wish I'd realized that before the past
several hours of struggling with something Yesod really doesn't want to
allow.
|
| | |
|
| |
|
|
|
| |
Due to being multicast, requests sent by one thread are received by the
listener in another thread.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The remote computer may not support mDNS. Instead, pass over the uname -a
hostname, and the IP address, and leave best hostname calculation to the
remote side.
|
| |
|
|
| |
also, tested on ipv6.. doesn't work
|
| |
|
|
|
|
|
|
|
|
| |
Pair requests are sent on all network interfaces, and contain the best
available hostname to use to contact the host on that interface.
Added a pairing in progress page.
Revert "reduce some boilerplate using ghc extensions", because it caused
overlapping instances for Text.
|
| |
|
|
|
|
| |
Actually 3 forms in one, this handles the initial passphrase entry, and the
confirmation, and also varys wording if the same user or a different user
is confirming.
|
| |
|
|
| |
yet more changes to pairing message data types
|
| | |
|
| |
|
|
|
|
| |
Only 2 messages are needed to do pairing.
And added a nice Verifiable data type.
|
| |
|
|
|
|
|
| |
Roughed out a data type that models the whole pairing conversation,
and can be serialized to implement it. And a state machine to run
that conversation. Not yet hooked up to any transport such as multicast
UDP.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Avoid trying to git push/pull to special remotes, but still do transfer
scans of them, after git pull from any other remotes, so we know about
any values that have been placed on them.
|
| | |
|
| |
|
|
| |
Doesn't set up the repo yet.
|
| | |
|
| |
|
|
| |
wow, that was easy!
|
| |
|
|
|
|
|
| |
I think this makes sense.. Unless the assistant is running on the server,
the repo won't be updated, so it might as well be bare.
Non-bare repos will be handled by the pairing configurator, later.
|
| |
|
|
| |
Rsync remote still needs work
|
| | |
|
| |
|
|
|
| |
for use by other configurators.. probably should be moved to a utility
module somewhere
|
| | |
|
| |
|
|
| |
also broke out webapp types into a separate module
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Avoids flicker to 0% when resuming a paused transfer.
|
| |
|
|
|
|
|
|
|
| |
The code to maintain that TChan in parallel with the list was buggy,
the two were not always the same. And all that TChan was needed for was
blocking on the next transfer, which can be accomplished just as well by
checking the size and retrying, thanks to STM.
Also, this is faster, and uses less memory. Total win.
|
| |
|
|
| |
don't want to stomp over fields other than the ones being changed
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
I had an intuition that throwTo might be blocking because an exception was
caught and the exception handler was running. This seems to be the case,
and is avoided by using try. However, I can't really find anywhere in
throwTo's documentation that justifies this behavior.
|
| | |
|
| |
|
|
|
|
| |
When multiple downloads of a key are queued, it starts the first, but leaves the
other downloads in the queue. This ensures that we don't lose a queued
download if the one that got started failed.
|
Joey Hess