On 6 Mar 2014, at 7:33 am, Marcin Erdmann <marcin.erdm...@proxerd.pl> wrote:
> 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? At this stage, I think it’s sufficient that the error message gives the user some idea that the credentials are incorrect. Eventually, it would be nice to tell the difference, if possible. > > 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? Yes, for now. I think at some point we will rework the ExternalResourceAccessor interface so that it can better deal with the fact that for some transports (file, sftp), the meta-data for a resource and the content for a resource have to be fetched as separate operations. The interface at the moment assumes that it’s cheap-ish to get the meta-data at the same time the content is requested. This way, the caller can decide whether it needs the meta-data or not, and invoke the appropriate operations - get meta-data, get content or get meta-data and content (if supported). -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
