gzip is discouraged? why say that?
I don't know! dflemstr must have written that when he first made the spec, and I didn't really notice it. I've removed the "and is discouraged".
The 'trust' approval thing sounds fishy; ie: how will a client know anything about these people, or how to trust them? or if an account gets decommissioned over time and a new guy with the same name comes along
I figured the user would know at least a few trustworthy people (eg. through the forums) and would tell the client program to trust them. Granted, there's no indication that a forum username would match a site username, or that usernames would stay constant; this problem even extends to the "vendor" field.
This wouldn't be a problem for sites that use a more centralized approval system (both can work the way I've layed it out here). Still, I agree it's pretty wacky, and I'm fine putting off validation stuff for a little while. I've heard of no malicious PNDs yet, and hopefully they'll hold off for a while longer.
I like to fall back to specs being 'minimal' -- that sounds 'site specific', so keep it out of the spec; a site is free to add _Additiona_ values to its own API withou tbreaking any consumer .. maybe that shoudl be codified in the spec -- the assumption that consumers will parse for known values, and not consider unknown key/values an error.
Yeah, I think sites should be able to add site-specific fields of the form "x-sitename-field", so as to avoid conflicts. I've added a note on this to the preamble.
Same question for 'rating'; is that too specific? ie: I could see one site uses 5-star, another using 100% .. they could map to some value system using this spec though, so it sounds doable; but just not sure its appropriate.
I figured mapping to a 100-point scale isn't too difficult. That's what Metacritic does. And repo maintainers can choose how to do the mapping themselves (or not include a rating at all).
-- drop the trust stuff -- keep the rating
I'm leaning towards that. Let's wait a bit for any further comments, then I'll make that change.
Licenses -- I forget offhand, but does that map to how we have the PXML licenses? ie: license and source are tied there, but not in this proposal;
Yeah, it's not an exact match. In the PXML, each license element can have a source attribute. I couldn't figure out how to make a clean mapping from the PXML license element to here without having a lot of unnecessary data, so I simplified. Multiple licenses make sense to me, but multiple source code URLs don't, especially with one tied to each specific license. So I figured the repository should pick one link and make that the source link. But I just realized I could make it a list of source links; they still wouldn't directly correspond to individual licenses, but at least they would all be there. How does that sound?
You may want to define what RESTY operations are available specifically; can an app enquire specifically about an app in the repo by itself to get additional details, etc?
I hadn't considered it. I figured a client would get the whole thing once, then parse it offline. This is how all Linux package managers I've seen work, so I thought it would suffice. Is there any real use to having specific inquiries?
Thanks a lot for the feedback Jeff. Anyone else?
Randy Heydon Tempel