absconding GET from webdav - was ( Re: service layer API proposal )

[Joakim Erdfelt <jo...@erdfelt.com>]

Second is the assumption that "GET" requests are not webdav requests.

Some WebDav client implementations improperly use the "GET" request to 
obtain file/folder information. (they should be using the various 
xml/propget requests to obtain that list.)

We could likely make it work, but in the process would reduce our 
already limited list of webdav clients down further.

/me glares at OSX.

(OSX's webdav client cannot be used against Archiva, due to bugs in the 
client)

- Joakim

Brett Porter wrote:
> I agree. Any reason we can't use detection?
>
> Also, any reason why the handler for downloading from the /repository/ 
> can't be this get servlet instead of dav servlet? We probably don't 
> want to add new ways to download from the repository for the same 
> reason we removed /proxy/. I realise you can only map one servlet, but 
> the servlet could delegate all operations other than get() to the dav 
> implementation.
>
> Anyway, not really sure of the implementation, just don't like 'get' 
> as a name :)
>
> I also don't agree on the repository storage format. I don't see any 
> reason this can't be configurable, and I think it's useful to be able 
> to run on an existing repo, or should we ever change the m2 format in 
> future.
>
> - Brett
>
> On 06/06/2007, at 4:18 AM, nicolas de loof wrote:
>
>> The "/get/{implementation-id}/{layout-path}" is an interesting option.
>>
>> Where would you place the target managed repository in such an URL ?
>>
>> The only thing I don't like in this solution is that it doesn't work 
>> based
>> on an auto-detection of the requested format. I'd prefer the servlet to
>> search for an implementation that accepts the requested path, so that 
>> the
>> current "/repository/id/{layout}" would be valid for any supported 
>> layout.
>>
>>
>> 2007/6/5, Joakim Erdfelt <jo...@erdfelt.com>:
>>>
>>> We have 2 concepts that are co-mingled right now.
>>>
>>> 1) Getting an artifact from Archiva.
>>> 2) Deploying an artifact to Archiva.
>>>
>>> This proposal should focus on #1, Getting an artifact from Archiva.
>>> (As for #2, that can remain the realm of the current DavServlet
>>> implementation)
>>>
>>> I always pictured this as a new GetArtifactServlet.
>>>
>>> Lets say we have it mapped to the "/get" servlet mapping.
>>> The following urls would all point to the same artifact.
>>>
>>> : Basic Format for maven 1 clients.
>>>
>>> http://hostname.com/archiva/get/maven1/org.apache.maven.wagon/jars/wagon-scm-1.0-alpha-3.jar 
>>>
>>> : Basic Format for maven 2 clients.
>>>
>>> http://hostname.com/archiva/get/maven2/org/apache/maven/wagon/wagon-scm/1.0-alpha-3/wagon-scm-1.0-alpha-3.jar 
>>>
>>>
>>> : (Advanced / Future Use) apt/deb serving.
>>>
>>> http://hostname.com/archiva/get/apt-deb/org.apache.maven.wagon/wagon-scm-1.0-alpha-3.deb 
>>>
>>> : (Advanced / Future Use) yum/rpm serving.
>>>
>>> http://hostname.com/archiva/get/yum-rpm/org.apache.maven.wagon/wagon-scm-1.0-alpha-3.rpm 
>>>
>>>
>>> Using a new servlet, would essentially decouple the filesystem
>>> format/layout as a requirement.
>>> Archiva can assume maven 2 format for the filesystem, and serve the
>>> artifact to the client in the way that is requested.  After all the 
>>> artifact
>>> information is now in the database.  It makes sense to me to do it 
>>> this way.
>>>
>>> The idea with the URL format is that
>>> "/get/{implementation-id}/{artifact-reference-implementation-format}"
>>>
>>> The implementation id can be a plexus role-hint on the 
>>> implementation of
>>> this GetArtifactServlet.
>>>
>>> What do you think?
>>>
>>> - Joakim
>>>
>>> nicolas de loof wrote:
>>>
>>> Hello,
>>>
>>> To enhance archiva-1.0 support for maven1, I'd like to introduce a 
>>> layer
>>> between DavServlet and repository proxies connectors.
>>> As Joakim suggested, this is the scope of the Dynamic Artifact Serving
>>> Layer
>>> in archiva roadmap.
>>>
>>> I propose this API :
>>>
>>> public interface ArtifactServingLayer
>>> {
>>>    /**
>>>     * Retrieve an artifact path in the repository based on the resource
>>> string.
>>>     */
>>>    public String getResourcePath( String resource );
>>> }
>>>
>>> The serving layer is responsible of finding the resource in the managed
>>> repository, with any required logic or temporary content, and to give a
>>> repository-related path back to the DavServer.
>>>
>>> The default implementation could simply use proxies-connectors to 
>>> find the
>>>
>>> resource, and some interceptors / proxies could add features, like
>>> converting on-the-fly from a layout format to the managedRepository
>>> layout,
>>> handle artifact relocation when a non-POM artifact is requested, or
>>> anything
>>> we discover to be usefull.
>>>
>>> What's your opinion ?
>>>

Re: absconding GET from webdav - was ( Re: service layer API proposal )

[Brett Porter <br...@apache.org>]

Ok, while I'd definitely prefer to make it work, if it can't then I'd  
prefer we made the change in the other direction (the default  
repository URL is get only, we have /repository-id/webdav/ as the  
webdav exposure point).

- Brett

On 06/06/2007, at 5:56 AM, Joakim Erdfelt wrote:

> Second is the assumption that "GET" requests are not webdav requests.
>
> Some WebDav client implementations improperly use the "GET" request  
> to obtain file/folder information. (they should be using the  
> various xml/propget requests to obtain that list.)
>
> We could likely make it work, but in the process would reduce our  
> already limited list of webdav clients down further.
>
> /me glares at OSX.
>
> (OSX's webdav client cannot be used against Archiva, due to bugs in  
> the client)
>
> - Joakim
>
> Brett Porter wrote:
>> I agree. Any reason we can't use detection?
>>
>> Also, any reason why the handler for downloading from the / 
>> repository/ can't be this get servlet instead of dav servlet? We  
>> probably don't want to add new ways to download from the  
>> repository for the same reason we removed /proxy/. I realise you  
>> can only map one servlet, but the servlet could delegate all  
>> operations other than get() to the dav implementation.
>>
>> Anyway, not really sure of the implementation, just don't like  
>> 'get' as a name :)
>>
>> I also don't agree on the repository storage format. I don't see  
>> any reason this can't be configurable, and I think it's useful to  
>> be able to run on an existing repo, or should we ever change the  
>> m2 format in future.
>>
>> - Brett
>>
>> On 06/06/2007, at 4:18 AM, nicolas de loof wrote:
>>
>>> The "/get/{implementation-id}/{layout-path}" is an interesting  
>>> option.
>>>
>>> Where would you place the target managed repository in such an URL ?
>>>
>>> The only thing I don't like in this solution is that it doesn't  
>>> work based
>>> on an auto-detection of the requested format. I'd prefer the  
>>> servlet to
>>> search for an implementation that accepts the requested path, so  
>>> that the
>>> current "/repository/id/{layout}" would be valid for any  
>>> supported layout.
>>>
>>>
>>> 2007/6/5, Joakim Erdfelt <jo...@erdfelt.com>:
>>>>
>>>> We have 2 concepts that are co-mingled right now.
>>>>
>>>> 1) Getting an artifact from Archiva.
>>>> 2) Deploying an artifact to Archiva.
>>>>
>>>> This proposal should focus on #1, Getting an artifact from Archiva.
>>>> (As for #2, that can remain the realm of the current DavServlet
>>>> implementation)
>>>>
>>>> I always pictured this as a new GetArtifactServlet.
>>>>
>>>> Lets say we have it mapped to the "/get" servlet mapping.
>>>> The following urls would all point to the same artifact.
>>>>
>>>> : Basic Format for maven 1 clients.
>>>>
>>>> http://hostname.com/archiva/get/maven1/org.apache.maven.wagon/ 
>>>> jars/wagon-scm-1.0-alpha-3.jar
>>>> : Basic Format for maven 2 clients.
>>>>
>>>> http://hostname.com/archiva/get/maven2/org/apache/maven/wagon/ 
>>>> wagon-scm/1.0-alpha-3/wagon-scm-1.0-alpha-3.jar
>>>>
>>>> : (Advanced / Future Use) apt/deb serving.
>>>>
>>>> http://hostname.com/archiva/get/apt-deb/org.apache.maven.wagon/ 
>>>> wagon-scm-1.0-alpha-3.deb
>>>> : (Advanced / Future Use) yum/rpm serving.
>>>>
>>>> http://hostname.com/archiva/get/yum-rpm/org.apache.maven.wagon/ 
>>>> wagon-scm-1.0-alpha-3.rpm
>>>>
>>>> Using a new servlet, would essentially decouple the filesystem
>>>> format/layout as a requirement.
>>>> Archiva can assume maven 2 format for the filesystem, and serve the
>>>> artifact to the client in the way that is requested.  After all  
>>>> the artifact
>>>> information is now in the database.  It makes sense to me to do  
>>>> it this way.
>>>>
>>>> The idea with the URL format is that
>>>> "/get/{implementation-id}/{artifact-reference-implementation- 
>>>> format}"
>>>>
>>>> The implementation id can be a plexus role-hint on the  
>>>> implementation of
>>>> this GetArtifactServlet.
>>>>
>>>> What do you think?
>>>>
>>>> - Joakim
>>>>
>>>> nicolas de loof wrote:
>>>>
>>>> Hello,
>>>>
>>>> To enhance archiva-1.0 support for maven1, I'd like to introduce  
>>>> a layer
>>>> between DavServlet and repository proxies connectors.
>>>> As Joakim suggested, this is the scope of the Dynamic Artifact  
>>>> Serving
>>>> Layer
>>>> in archiva roadmap.
>>>>
>>>> I propose this API :
>>>>
>>>> public interface ArtifactServingLayer
>>>> {
>>>>    /**
>>>>     * Retrieve an artifact path in the repository based on the  
>>>> resource
>>>> string.
>>>>     */
>>>>    public String getResourcePath( String resource );
>>>> }
>>>>
>>>> The serving layer is responsible of finding the resource in the  
>>>> managed
>>>> repository, with any required logic or temporary content, and to  
>>>> give a
>>>> repository-related path back to the DavServer.
>>>>
>>>> The default implementation could simply use proxies-connectors  
>>>> to find the
>>>>
>>>> resource, and some interceptors / proxies could add features, like
>>>> converting on-the-fly from a layout format to the managedRepository
>>>> layout,
>>>> handle artifact relocation when a non-POM artifact is requested, or
>>>> anything
>>>> we discover to be usefull.
>>>>
>>>> What's your opinion ?
>>>>