I finally got my head around the contract of ExternalResourceAccessor and after doing some reverse engineering of HttpResourceAccessor and Ivy's SFTPResolver as well as skimming SFTP protocol specs the following are my findings and questions:
Error handling is far from perfect in both clients - they only return a generic error when you try to get file metadata for a file that doesn't exist but there seems to be a specific substatus for such situation called SSH_FX_NO_SUCH_FILE. I can see that this substatus is returned by SSHD's implementation of SFTP server when accessing files that don't exist even though the spec( http://tools.ietf.org/id/draft-ietf-secsh-filexfer-00.txt) cryptically describes it as "is returned when a reference is made to a file which should exist but doesn't" - this should but doesn't part baffles me a bit. Anyway I will assume that this substatus is returned whenever trying to stat a non-existing file. I'm going to use SSHD's client as it seems to be better maintained and I like it more. I will be also able to easily change it's behavior when it comes to handling the aforementioned SSH_FX_NO_SUCH_FILE substatus. We will probably want to throw a specific contextual exception when credentials are incorrect, right? It feels like we want to have separate ssh sessions for getting metadata and getting the file - the fact that you request an ExternalResource doesn't mean that you will ever read it and thus close it, but you need to open a ssh session to get the metadata. So the idea here is to open a session, get metadata to see if the resource exists and close the session possibly passing the metadata to the created ExternalResource if the resource exists. Then, if resource contents are requested open a new session and close it when close() is called on the ExternalResource. Are we ok with such approach? I can't seem to find a way of reusing sessions without ending up with dangling ssh sessions in some situations. Cheers, Marcin On Wed, Feb 26, 2014 at 10:00 PM, Adam Murdoch <adam.murd...@gradleware.com>wrote: > > Looks good to me. I've added a few more things - we should reuse the > transports and caching for remote build scripts, and add some basic > credentials management as well (eg prompting at the command-line, tooling > API integration) > > On 24 Feb 2014, at 1:46 pm, Daz DeBoer <darrell.deb...@gradleware.com> > wrote: > > I've pushed an initial cut of the spec: feel free to modify as you > discover things that don't make sense. > > https://github.com/gradle/gradle/blob/master/design-docs/repository-transports.md > > > > On Sun, Feb 23, 2014 at 4:10 PM, Marcin Erdmann <marcin.erdm...@proxerd.pl > > wrote: > >> 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 >>> >>> >>> >>> >> > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > > >
