update

1 files changed, 16 insertions, 4 deletions

diff --git a/doc/todo/support_for_writing_external_special_remotes.mdwn b/doc/todo/support_for_writing_external_special_remotes.mdwn
index eab0c5dff..2d7cd9d15 100644
--- a/doc/todo/support_for_writing_external_special_remotes.mdwn
+++ b/doc/todo/support_for_writing_external_special_remotes.mdwn
@@ -1,13 +1,25 @@
-It would be good to have something in between the hook special remote and the built-in special remotes.
-The hook is easy to set up, but its simple interface misses some features that a more full-features interface could provide to a third-party program that wants to provide the best possible special remote it can w/o being written in haskell:
+It would be good to have something in between the hook special remote and
+the built-in special remotes. The hook is easy to set up, but its simple
+interface misses some features that a more full-features interface could
+provide to a third-party program that wants to provide the best possible
+special remote it can w/o being written in haskell:
 
 * No way to send progress updates when uploading, so no progress bars for uploads from hook special remotes in the webapp.
 * No way to verify the `initremote` parameters include all needed configuration, and do any initalization needed.
 * No way to query and/or set the remote.log while it's running. (Well, technically, `git annex enableremote` can set values..)
 * No way to store per-key information to the git-annex branch.
+* No (easy) way to split files into chunks.
 
-These features could be added to git-annex as subcommands. Which would improve the general programmability and flexability of git-annex. OTOH, running `git-annex upload-progress` repeatedly is pretty ugly. Or the interface could provide a channel for the program and git-annex to communicate back and forth on. Maybe a mix of the two?
+Some of these features could be added to git-annex as subcommands. Which would
+improve the general programmability and flexability of git-annex. OTOH,
+running `git-annex upload-progress` repeatedly is pretty ugly. Or the
+interface could provide a channel for the program and git-annex to
+communicate back and forth on. Maybe a mix of the two?
 
-A final feature such an interface should provide is the ability to drop a program into PATH and have it just work, without the user needing to do any configuration beyond `initremote`. So, `git annex initremote foo type=$bar` should look for `git-annex-remote-$bar` in PATH if that's not a built-in special remote name.
+A final feature such an interface should provide is the ability to drop a
+program into PATH and have it just work, without the user needing to do any
+configuration beyond `initremote`. So, `git annex initremote foo type=$bar`
+should look for `git-annex-remote-$bar` in PATH if that's not a built-in
+special remote name.
 
 --[[Joey]]