On Thu, Aug 05, 2010 at 02:02:49PM -0700, Shawn Walker wrote: > On 08/ 5/10 01:20 PM, [email protected] wrote: > >I'm also a bit concerned about how we determine whether POST for file/1 > >is enabled by the client. Up to this point, the versions/0 information > >tells us whether the depot supports a particular operation, and what > >versions are supported. If a depot isn't providing a particular > >operation, the operation string is absent in the versions/0 information. > >However, with file/1, we can support GET file/1, but not POST file/1. > >The versions/0 information doesn't currently have a way of expressing > >this. Shawn may not agree with me, but perhaps add_cert, or whatever > >you had before, is actually preferable? Thoughts? > > add_cert isn't preferable was we ultimately need a generic file > upload mechanism anyway, which is all that's being done here. > There's nothing about this operation that makes it specific to > certs. > > I don't think it's desirable to have a separate operation for every > possible variant of an existing operation. And as I've mentioned > before, from an HTTP standpoint, it makes more sense to support PUT, > GET, etc. for a single part of the namespace and reject operations > as appropriate.
How do you propose that we determine if POST file/1 is enabled? Try and fail isn't presently feasibile. When we developed the new transport, the plan was to use versions/0 to see what operations a depot supported, and only contact the depots that support the desired version. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
