On 8/22/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > On 22 Aug 07, at 11:23 AM 22 Aug 07, Gregory Kick wrote: > > > > >> > >> It does if you use a shared file system, many people actually use > >> this. And simple Window file perms work here to protect it. > > > > How do you deal with concurrent writes? > > > > There's nothing you can do here with Wagon in general right now. This > is not local to the file wagon.
That was my point. Without some sort of server interception, you can't solve that problem, so file-based remote repositories on shared drives are probably a bad idea... > > >> > >>> , all of them require some sort of > >>> server somewhere. Granted, a lot of people have sshd or httpd or > >>> ftpd > >>> running so it's not an extra process, but there's still _something_ > >>> running on the other end no matter what. Also, I'd be pretty > >>> surprised to find that a significant portion of the people running a > >>> remote repository weren't running a servlet container already as > >>> well. > >>> Plus, there's always jetty or winstone if you want a quick install. > >>> > >> > >> No argument that in the very near future I don't think anyone will > >> use a Maven repository without a front-end application. Web servers > >> are just too stupid, security is annoying, you have no transactional > >> behaviour, and you have to expose the internal structure. > >> > >>> I'm also pretty sure that there's going to be some question of > >>> backwards compatibility. Well, seeing that I'm suggesting a RESTful > >>> service, it could have the exact same structure as what's being used > >>> now. I'm not entirely sure I'd recommend that, but it _could_. > >>> If it > >>> didn't you could always just add a new layout. > >>> > >> > >> The repository managers will have an API, and can be exposed via REST > >> which will end up being one of the favored modes of operation. But I > >> see applications interacting directly with client side APIs to get > >> things done. Like Maven deployments, releases, searching, what > >> have you. > > > > This seems like it'd end up being problematic for a couple of reasons. > > The first is that when you say that it _can_ be exposed via REST this > > implies too much flexibility in what the resource URIs look like. > > There's no reason that there can't be a standard URI, but honestly I > don't see the REST API being the most used form of access. You expect a transport other than http to be most common? Which? > > > To > > provide a decent user experience from both the application and the > > browser, there has to be some standardization for the rest api. > > Not disagreeing with you. > > > Not > > that the current layout doesn't have a standard interface, but the > > format of the results for directory listings and the URIs for > > additional functionality would end up being all over the place. > > What is used to logically represent an artifact via a URI can be > decoupled from where it resides physically. Looking directly at the > web server is not necessarily representative of what the REST API > would provide. I'm not sure that I'm on the same page with what you mean by "physically." I think physical in terms of mean where it is on disk, which even with just raw apache can have little/nothing to do with what uri it's served from. So, if you were to use additional uris to represent a given resource, the typical http://.../group/artifact/version/blah.jar would still be the cannonical uri if it's available as well. For that reason, I envisioned a REST api that was a superset of the GET requests that the lightweight http wagon uses now. > > > > > The other issue is that, from a developer perspective, I'd rather > > there not be a standard java api. If the job of a repository is to > > serve artifacts, that should be the only contract to which I'm bound > > (especially if the maven code is still compiling with 1.4). > > It's not the only responsibility of the repository, and I disagree > that people won't want to use an API. But again, there is no reason > that we can't have a standard REST API built upon the standard API > which would satisfy your primary concern. For pulling artifacts 9/10 > people will most likely use HTTP, but we have many people using SCP > and FTP for whatever their reasons. > > > Unless > > there's a really compelling reason to support other transports, > > Existing users that are not pulling with HTTP. Yeah, and that's definitely a concern, but I wonder whether that's a result of infrastructure requirements or the fact that you currently have to jump through so many hoops to push with http/webdav. > > > any > > additional api just adds another layer. Of course, the maven-built RI > > could add whatever api it wants, but I can't think of a scenario in > > which you'd need to support its invocation from anything other than > > the transport. > > > > A repository manager will ultimately be responsible for more then > pulling artifacts. For pulling and the 9/10 people using HTTP, and > for those who simply want access to the repository we can provide > this common REST API and no one will be the wiser. But for > deployments, releases, searching, retrieval of incremental indices, > retrieval of stats a standard API will be of greater use. It's what > we would use directly from Maven and any tooling would be more > interested in using this API. I guess my point was more that given full push and pull support over http, scp and ftp probably wouldn't have had much use. So, if we're finally to the point where it makes sense for repositories to have a server-side presence we can move towards a unified transport that supports push, pull and algorithm execution. REST makes sense to me because you can see it in a browser and still support _all_ of the operations on repository. Otherwise, how do you get stats via SCP or FTP? How do you search without making the client do all of the work? >From the sounds of it, you're separating the duties of the repository from the repository manager, but with issues like transactional deployment, you really have to have that be a function of the repository, otherwise you have to enforce that all deployment go through the manager. (right?) If that's the case then you're exposing push and pull via some transport and your other ops (e.g. stats) via another. I guess the whole point is that the current system is all over the place and has some issues. Given all that we know now, and all that we know that people want to do with repositories, is it feasible/reasonable/desired to support this whole multi-transport abstraction for repositories with a server-side presence? > > >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder and PMC Chair, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Gregory Kick http://kickstyle.net/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
