Thanks Mark.Excellent - better to find the conflicts now than later.On a related note, we should also have media types (and supporting RFCs) for the appropriate http interactions. We did that for CDMI (http://tools.ietf.org/html/rfc6208) Makes it easy for ops and implementations ...Cheersk/
Couple of quick points:a) Once the ports are fixed, we should register them with IANA as well known ports, which is the right place.[http://www.iana.org/assignments/port-numbers]b) I was going to suggest something like a ZooKeeper, may be the service catalog serves that purpose.c) Also, on the
Couple of points:a) We do need a North-facing interface that supports headless operation incl billing, reporting and so forthb)IMHO, REST APIs are better than SOAP interfacesc) Also JSON might be a good choiced) There are already other cloud APIs available like the vCloud, OCCI et al. OCCI
Good stuff. Couple of questions:a) Looks like one of the major drivers is the rules based scheduling - mutual exclusion, temporal and spatial rules, and so forth. Is there an existing way to capture these placement pragmas ? Or should we have a light rules framework ? b) Saw your note "I am
Eric, Thanks for your experimentation and analysis. Somewhat illustrates the point about premature optimization. First cut, have to agree with you and conclude that python implementation is effective, overall. As you said,if we find performance bottlenecks, especially as the payload size increases
On the topic of a REST API for the queue, I think implementing the CDMI queue APIs might be a good choice.The spec is at http://www.snia.org/tech_activities/publicreview/CDMI_Spec_v1.01f_DRAFT.pdf. There are a few other things, but focus on Section 11 P.104, Queue Object Resources. BTW, cdmi-queue
6 matches
Mail list logo
