Could it get by with just a list of known licenses across source and not list source links; or if the source references should be in there, then make it map to the PXML so we don't run into chaos.
I'm not sure what you mean here. Could you clarify?
If too hard, then just a list of licenses, and a list of source references, and milkshake can note the consmer has to figure out which are which.
"App is under BSD and GPL licenses" "Sources are: (1) ... (2)..."
Yep, this is what I was saying. Better than my current single source link, but still doesn't capture all of the nuances of the PXML.
# > 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?
Put it into the spec; RESTy often implies GET PUSH etc, so should define which are supported.
The spec mentions that GET and HEAD requests must be available on the main repo data. There's currently no other data to be accessed, and no way to modify the data through the spec (ie. no need for PUT, POST, or DELETE), so I don't think there's a need to say anything more on them. Then again, my knowledge of REST is entirely from some quick reading early this morning, so I might not know what I'm talking about.
I hope that's about it. I want to firm this up quickly so milkshake can get to implementing it and I can get back to work. I thought my thesis was almost done, but it turns out my advisors disagree, so I'll be strapped for time for a few more weeks. But maybe I shouldn't be complaining about how busy I am to Jeff :P
Randy Heydon Tempel