*"caproles": Capabilities and Roles in the Registry *DAL and Registry May 13, 15:00 UTC Participants: 11 Slides (live): https://telco.g-vo.org/p/lpln/ Slides (not live, past, May 2019 Interop): https://wiki.ivoa.net/internal/IVOA/InterOpMay2019Reg/caproles.pdf Caproles Note: http://www.ivoa.net/documents/caproles/20190315/index.html *What's the problem (very much in a nutshell)? * We are defining variable properties of services at the resource level. * e.g., availabilty would need to sit on accessURL/mirrorURL, not on resource: how does a client know what accessURL that availabilty describes? * e.g., tables: that may vary by authentication, and hence on the interface level * Paul Harrison: Note most of the practical issues are in and around VOSI, what minimal changes we need we can make within the registry model we have. * the original motivation of the caproles was to alter the registration pattern that was proposed for tap 1.1 - the original registry model did have - capability == some form of functionality - e.g. TAP - interface == the style of the interface e.g. rest vs SOAP - access_url == the url that the particular interface - might have multiple instances for mirrors etc. I think that on one level we can make the first step of this change with literally only some documentation changes and possibly some de/re-registrations The endpoints proposal is a change in the schema, and it allows for some extra metadata to be added at that level - however it is not clear that this is actually required if no-one wants to add anything more at that level [Markus: CADC signals they have use cases; I personally suspect that most extensions can work on the basis of try-and-fail, as in: if there's no examples endpoint, you get a 404; if you can't post to tables, you'll get a method-not-allowed, etc. However, I can see not everyone likes that pattern.] I think that the core of the "mistake" in the application of the registry model in the past was the fact that capabilities was viewed as a capability in itself rather than an abstract base class for a particular interface style - part of the caproles proposal is to introduce a new interface DALIInterface that essentially says that the capability is DALI compilant with all the VOSI etc endpoints effectively assumed. * Use on CADC: - Capabilities are used for all CADC services (even non VO services) - Client use them to discover the supported securityMethods. - Clients use them to determine what optional features are supported * q: Mark Taylor: What's the *immediate* issue if what's out there now works * a: bundling and organizing endpoints, per prior authenticated endpoints discussion. less so with proposed A+A changes now * a: Will reappear when we start describing mirrors * a: TAP 1.1 endpoints not necessarily derivable from main URL, but clients still assume they are. Will need to explain or sort this. * Paul: Changes to how we register/describe/lean on VOSI alone could fix this? * General solutions: * move the metadata to appropriate sections of resources, offload the variable portions to service interfaces rather than resource, etc..... The direction Markus wants do go: DALIInterface * many of the different endpoints really end up on interface. Let's have them there * nb, availability is a special case and needs to be fixed on the accessURL level * VOSI changes (Paul): Remove VOSI as capability set on its own? But then where does registration of these endpoints go. And can/should we assume their relative endpoints as we do now.? Markus' stance: Essentially, I guess so. There's a tricky part where "simple" protocols (e.g., SCS, SSAP, Datalink) want guessable capability URIs. But I think we ought to have an actual use case for that (and someone who'd like to consume such capabilities) before worrying about that too much. *Takeup issues? * Markus: (Most of?) what needs changed is not being used YET. Marco: even if that's true, I still have concerns from the client side point of view and validation of services. [Markus, after session: Ok, there is one thing that's a problem in migration: "classic" discovery based on interface='vs:ParamHTTP'; as long as clients still do that, we'll have to keep these, probably in addition to newer, more comprehensive mechansims. Theresa: MAST is using availability pieces we're proposing to change, for internal validation and uptime. * Availability by mirror will run into these problems, not used yet * Authenticated endpoints * Brian Major: feedback from CADC, changes to use tokens for authentication may alleviate this problem case * (The current state of things is still wrong, but the new CADC approach alleviates a requirement to fix that portion ASAP) * Brian: CADC has found the extended capability information useful for other services (incl non-VO) and are actively using pieces we are considering moving. Markus: We definitely want to still support extensions of all kinds -- it just shouldn't and cannot be always through extra capabilities. *Can we start going? * WHERE do we start? TapRegExt 1.1 * Mark: What's the worst if we take things apart and abandon the reorg [Markus: we won't break what works in TAP 1.0, so the worst thing is that we waste time on trying to establish a pattern that nobody will use later. But, really, my current plan is just blessing the actual practice with proper standard language] * Does this become incompatible with currently used portions of VOSpace? Currently unused ones? [Markus: yes, the VOSpace pattern is probably incompatible with caproles claims, though I have not properly analysed it. However, I suspect that the current VOSpace registration pattern will be difficult anyway as soon as a VOSpace client actually tries to use the registry, together with figuring out, e.g., auth or VOSpace as part of TAP, or similar] * Paul: we'll need to look at what this does to VOSI at the same time * DALI service endpoints vs explicitly listed paramhttp * Brian: What do we gain / what do we lose? gain: cleanup. lose: functionality CADC is using. * Paul, Markus: to draft TapRegExt changes. Will want CADC input as they're most affected in current practice. VODataService next. liste of participants Theresa Dower Marco Molinaro Mark Taylor Markus Demleitner Paul Harrison Tess Jaffe Chritophe Arviset François bonnarel Brian Major Pierre Le Sidaner Kostas Vrioni