Sounds like a plan.
On Sun, Feb 23, 2014 at 11:02 PM, Adam Murdoch <adam.murd...@gradleware.com>wrote: > > On 24 Feb 2014, at 9:36 am, Marcin Erdmann <marcin.erdm...@proxerd.pl> > wrote: > > > > > On Sun, Feb 23, 2014 at 10:33 PM, Daz DeBoer < > darrell.deb...@gradleware.com> wrote: > >> >>> I didn't get much time to have a look at this stuff this weekend because >>> I spent it contributing to Ratpack but I seem to have found test code that >>> exercises transports so I should be able to get started this week. I will >>> look at this code more and start drafting the design spec. >>> >> >> Excellent. I was planning on putting a first draft of the design spec up >> today; likely pretty basic to start with. >> > > Would be great if you could draft it. You probably have a much better idea > about the requirements than I do. > > > If you're keen to get started while we're getting the spec together, you > might do a quick spike with one or both of the clients to see what's > required to get them to talk to an ssh server, and if you have a preference > between sshd or jsch. You could even start with an integration test that > uses the sshd test fixture and drives the client(s) directly. We could then > refactor this into the real implementation. > > The sorts of things we'll need to be able to do: > > - Read the meta-data for a file, including whether it exists or not, plus > the size and last modified time of the file. > - Read from a file. > - Write to a file. > - Create file. > - List the entries of a directory. > > When things fail, it would be really nice to be able tell the difference > between a failure where the thing did not exist, vs a failure where there > is some permission problem, vs the server is not running, vs everything > else. > > I suspect error handling will be the deciding factor between the two > clients. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > > >
