Querying Gallery Capabilities

Coordinator
Nov 4, 2010 at 4:53 PM

The sorting discussion brings to mind another related issue we should discuss. We need a way to know which features/capabilities a gallery supports. For example, if a gallery doesn't support ratings, we need to know that so we don't even show the option to sort by rating.

Another example is that we also want to have the NuGet client display an URL for reporting bad packages. This would take the user to a page on the gallery where they can provide some information about a bad package. So we need the gallery to provide us that information.

So I'm thinking we need a way to query the gallery for its capabilities. Is there anything like that planned or implemented already? 

Here's a quick list of some of the things we may need to query the gallery for:

  1. Does it Support Ratings
  2. Does it provide download numbers
  3. The name of the gallery
  4. The URL to report bad packages
  5. The gallery homepage URL
  6. The gallery disclaimer notice

#6 is the message we show when you first connect to a gallery. It says something like: 

Each package is licensed to you by its owner. Gallery Name is not responsible for, nor does it grant any licenses to, third-party packages. Some packages may include dependencies which are governed by additional licenses. Follow the package source (feed) URL to determine any dependencies.

Coordinator
Nov 4, 2010 at 5:05 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Nov 4, 2010 at 7:18 PM
Edited Nov 4, 2010 at 7:18 PM

We don't currently have any plans to provide the ability to query the gallery for it's capabilities. I think supporting rating and download numbers is going to be assumed in any instance of the gallery. That was always the plan from the beginning as far as I know. The other items like the name of the gallery and the URL's for the home page/reporting bad packages will probably be configurable items on the back-end (most likely just settings in web.config).

Coordinator
Nov 4, 2010 at 7:39 PM

This approach makes sense to me.  ReportAbuseUrl, TrackingUrl, and the name of the feed should be configurable on the backend, along with anything else the backend needs to know about the front-end website it's configured against (like the endpoint to use for authentication/authorization, etc).

We can probably assume the website will always support ratings and download counts, and not make that a configurable/optional thing for now.  At least, the two galleries we are planning to set up initially (Orchard, NuPack) will both need these features, so it's just extra work to make it optional.

Phli brings up a good point regarding the Disclaimer text for gallery visitors - can this just be somewhere in the footer of the site?  We probably also need users to accept a "Terms of Use" upon creating a user account with the gallery, similar to the experience when you create a new account on codeplex.com.  Since we know that any package submitter will need to perform this initial step before submitting any packages (either through the website forms or command-line tools against the backend), it's a good place to put the terms that submitters need to accept.  The terms will likely be different per gallery instance, so having a file on disk we can edit to alter the terms of use sounds like a good idea.

Developer
Nov 4, 2010 at 7:53 PM

Yes, I think we can make things work well on the client without adding this new capability querying requirement.

As for ReportAbuse and Tracking, they are I think orthogonal to this discussion, since they are item level, and not feed level.  i.e. from the client's point of view, they're just regular fields that packages in the feed may have.  If they're not there, then the client simply won't display those links.

Coordinator
Nov 4, 2010 at 8:46 PM

Well we still need the disclaimer text to come from the feed somehow. That gets displayed in the Add Library Package Dialog as well as in the Package Manager Console when you connect to a new feed.