[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: AMQP Management Workstream
BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft Exchange Server 2010 VERSION:2.0 BEGIN:VTIMEZONE TZID:Pacific Standard Time BEGIN:STANDARD DTSTART:16010101T020000 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER;CN=Rob Dolin (MS OPEN TECH):MAILTO:robdolin@microsoft.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=amqp@lists .oasis-open.org:MAILTO:amqp@lists.oasis-open.org DESCRIPTION;LANGUAGE=en-US:(Forwarding to the full AMQP TC)\n\n-----Origina l Appointment-----\nFrom: Rob Dolin (MS OPEN TECH)\nSent: Monday\, May 20\ , 2013 4:08 PM\nTo: Rob Dolin (MS OPEN TECH)\; rafaels@redhat.com<mailto:r afaels@redhat.com>\nSubject: AMQP Management Workstream\nWhen: Tuesday\, M ay 21\, 2013 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).\nWher e: Lync: +14257063500 | 282 415 439 #\n\n\nHi Rafael\,\n I’m hoping this time tomorrow (after the AMQP BindMap TC meeting) might work for dis cussing your feedback on the AMQP Management spec. Thanks very much—\n- -Rob D.\n\n(See bottom of email for hyperlinks to call-in numbers)\n\n\n-- ---Original Message-----\nFrom: amqp@lists.oasis-open.org<mailto:amqp@list s.oasis-open.org> [mailto:amqp@lists.oasis-open.org] On Behalf Of Rob Doli n (MS OPEN TECH)\nSent: Friday\, May 17\, 2013 6:52 AM\nTo: rafaels@redhat .com<mailto:rafaels@redhat.com>\nCc: amqp@lists.oasis-open.org<mailto:amqp @lists.oasis-open.org>\nSubject: RE: [amqp] RE: AMQP Management Workstream \n\nTHANK YOU very much Rafael for your thoughtful comments.\n\nI'm going to work on addressing / incorporating them into a Doc using track changes and will schedule a ConCall with shared screen for review next week. Plea se let me know if you have any conflicts with the following days/times:\n* Tue\, 11am Eastern / 8am Pacific\n* Tue\, 1pm Eastern / 10am Pacific\n* W ed\, 11am Eastern / 8am Pacific\n\nIf others have comments\, please also s hare on the list.\n\nThanks very much--\n--Rob D.\n\nP.S. Once the call is scheduled\, I'll send the info to the AMQP TC so folks who are interested in participating can join.\n\n\n-----Original Message-----\nFrom: Rafael Schloming [mailto:rafaels@redhat.com]\nSent: Wednesday\, May 15\, 2013 9:0 8 AM\nTo: Rob Dolin (MS OPEN TECH)\nCc: amqp@lists.oasis-open.org<mailto:a mqp@lists.oasis-open.org>\nSubject: Re: [amqp] RE: AMQP Management Workstr eam\n\nI've been working through the document and do have some comments. I 'll summarize them below. I'm happy to discuss over email or at a call\, w hichever you prefer.\n\n - Section 3\, the treatment of case seems to be confusing/inconsistent.\nThe first para has operations in lowercase\, the second in uppercase\, and the table in 3.1 says that the operation is case sensitive and then goes on to say that it SHOULD be in ALL UPPERCASE. Thi s confused me at first because if the field is case sensitive then it need s to match exactly how the operations are defined\, so simply defining the standard operations to be "CREATE"\, ... rather than "create" should be s ufficient. I think what is being said in the latter part is really attempt ing to establish a naming convention about how custom operations should be defined and as such is not really directly related to the formal definiti on of the field. I would suggest it would be clearer to either define it e lsewhere or simply omit it entirely. (As an aside\, the example in para 2 of section 3 seems to violate this naming convention:\n"CreateNewTopic")\n \n - Section 3.1: the locales description was a bit confusing\, it took m e a reread to figure out that it was talking about what locale to use for the response.\n\n - Section 3.3 (UPDATE): are updates atomic?\n\n - Sect ion 3.3 (READALL): if this does get extended to include filters\, e.g. as suggested on type\, then READALL might be a bit of a misnomer. It also occ urs to me that the response could end up being very very large if you are indeed querying all manageable objects for a given system\, even if you ca n restrict to a given type. This brings to mind more generic filtering/que rying capabilities. I know pagination is something that consoles will run into right away. Perhaps we should consider the pros/cons of defining a st andard way to do paging and/or querying in order to handle incrementally r eading and/or narrowing the subset of data.\n\n - Section 3.3 (DISCOVER): this seems to be mixing both metadata (information about the types and op erations) with operational data (the names of the actual instances). One q uestion that comes to mind is why include names but not ids? This seems li ke it could lead to confusion if the names change. Perhaps the ids should be included also in these sorts of list results. Secondly\, I don't think it is a good idea to mix metadata and operational data in this way. It str ikes me that management consoles would likely want to be able to query the se separately\, e.g.\nquery the metadata alone on startup when configuring the UI and then separately refresh operational data as things change. For cing both the metadata and the operational data to be pulled down at the s ame time seems both less efficient and more awkward for at least some scen arios.\n\n - Section 3.3 (DISCOVER-MGMT-NODES): The model in general here could use some more explanation. I struggled to figure out why you needed so many different operations that all basically boil down to directory li sting\, and to be honest I'm not convinced you actually do need so many di fferent ones. It would be possible to collapse these with some changes/sim plification to the model. It appears there are at least 3 different naming schemes involved here: ids\, names\, and addresses.\nFurthermore addresse s are used in two ways. A manageable entity such as a queue might have an address\, and a manage*ment* entity might be accessible via an address. At a minimum this needs to be explained better\, but IMHO could use some sim plification.\n\n - Section 3.3 (REGISTER & DEREGISTER): this functionalit y seems odd to me as part of a basic manageable entity. This would seem to imply that all management nodes need to function as general purpose direc tory services.\n\nGeneral comments:\n\n - It seems odd to use names as ke ys for operations when we have unique and immutable ids\, renaming comes t o mind as something that would be more obvious/possible this way.\n\n - O verall I found it difficult to decipher the data structures as presented. There are actually a whole lot of highly structured types being defined he re via English. It would be a whole lot more precise to model these via fo rmal XML definitions.\n\n - There doesn't seem to be any notion of events or live updates or stats. This can to some extent be treated as an orthog onal problem and addressed as an independent chunk of work\, but it would be nice to see some early thinking about if/how this would intersect.\n\n - It might be nice to have some way to get a hint of how many results the re are likely to be from the directory listing operations. That would at a minimum allow a console to avoid pulling over more information than it ca n usefully/conceivably display. You can also imagine adding some kind of l imit to get only the first N results back.\n\n--Rafael\n\n\n.............. .......................................................................... .................................................\n--> Join Lync Meeting<h ttps://join.microsoft.com/meet/robdolin/GGGQLPW8>\n\nJoin by phone\n+14257 063500 (USA - Redmond Campus) English (United States)\n+188832 03585 (USA - Redmond Campus) English (United States)\nFind a l ocal number<https://join.microsoft.com/dialin>\n\nConference ID: 282 415 4 39\n\n Forgot your dial-in PIN?<https://join.microsoft.com/dialin> |Help<h ttp://o15.officeredir.microsoft.com/r/rlidLync15?clid=1033&p1=5&p2=2009>\n \n[!OC([1033])!]\n........................................................ .......................................................................... .......\n\n\n\n\n SUMMARY;LANGUAGE=en-US:FW: AMQP Management Workstream DTSTART;TZID=Pacific Standard Time:20130521T080000 DTEND;TZID=Pacific Standard Time:20130521T090000 UID:040000008200E00074C5B7101A82E00800000000D0AF92307455CE01000000000000000 01000000024102041EA9EAD409F19ABAA679EF6D3 CLASS:PUBLIC PRIORITY:5 DTSTAMP:20130520T230755Z TRANSP:OPAQUE STATUS:CONFIRMED SEQUENCE:1 LOCATION;LANGUAGE=en-US:Lync: +14257063500 | 282 415 439 # X-MICROSOFT-CDO-APPT-SEQUENCE:1 X-MICROSOFT-CDO-OWNERAPPTID:1962170333 X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-DISALLOW-COUNTER:FALSE BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT15M END:VALARM END:VEVENT END:VCALENDAR
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]