Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "20071128 IGF teleconf notes"
| (One intermediate revision by the same user not shown) | |||
| Line 7: | Line 7: | ||
| − | * Do a dynamic config/registry example (Jim will do) | + | * Talked about the way contexts are configured and discovered. |
| + | ** It would be good if there was a more dynamic way than hand-writing XRDS documents | ||
| + | *** Do a dynamic config/registry example (Jim will do) | ||
* Need dynamic discovery of what can go into a configuration | * Need dynamic discovery of what can go into a configuration | ||
| − | + | * An IGF identity stack could consist of a stub that uses Apache license | |
| − | * | + | |
** Can use Higgins or other stack to provide services to that stub | ** Can use Higgins or other stack to provide services to that stub | ||
| − | |||
* Reviewed http://www.openliberty.org/wiki/index.php/IGF_Architecture#Servlet_Application | * Reviewed http://www.openliberty.org/wiki/index.php/IGF_Architecture#Servlet_Application | ||
** From an application's POV, all data looks the same whether pushed (i.e. incoming token), or pulled (i.e. backend data source) | ** From an application's POV, all data looks the same whether pushed (i.e. incoming token), or pulled (i.e. backend data source) | ||
| Line 20: | Line 20: | ||
** Phil is thinking everything from Caching & Optimization down from http://www.openliberty.org/wiki/uploads//0/0c/Arch-Servlet.gif could be done in Higgins. | ** Phil is thinking everything from Caching & Optimization down from http://www.openliberty.org/wiki/uploads//0/0c/Arch-Servlet.gif could be done in Higgins. | ||
** Tom: What does the Caching & Optimization layer do? | ** Tom: What does the Caching & Optimization layer do? | ||
| − | *** Can analyze | + | *** Can analyze incoming operations (like CARML statements) and do things like prefetch (which may consist of multiple underlying operations) data and store it in mem. |
| − | ** Routing can handle | + | ** Routing layer can handle things that the existing IdAS registry does, but can also deal with mapping -- though maybe that should be done by a mapping provider? |
** Jim: when are the CARML statements passed? | ** Jim: when are the CARML statements passed? | ||
| − | *** | + | *** There can be a CARML declaration passed at a preconfig time, can be sent as a separate file up front which can be reviewed by an auditor, |
**** Up front stuff can declare what the client app expects to do/see in terms of operations, schema, etc. | **** Up front stuff can declare what the client app expects to do/see in terms of operations, schema, etc. | ||
**** Could also have CARML declarations associated with a transaction (like NewUserRegistration) | **** Could also have CARML declarations associated with a transaction (like NewUserRegistration) | ||
| Line 29: | Line 29: | ||
*** Partial data was returned, and here's why | *** Partial data was returned, and here's why | ||
*** Data exists, but consent is needed before it's released | *** Data exists, but consent is needed before it's released | ||
| − | + | * Talked about how IdAS can be extended to handle the passing of CARML and AAPML policy data | |
| − | * | + | ** Revive thread on API extensibility (Jim will do) |
| − | + | * Fix jspolicy cp so it will compile (Jim, Tom, or Duane will do) | |
| − | * Fix jspolicy cp (Jim, Tom, or Duane will do) | + | |
Latest revision as of 16:41, 28 November 2007
notes from 20071128 teleconf meeting.
On call:
Duane Buss
Jim Sermersheim
Phil Hunt
Tom Doman
- Talked about the way contexts are configured and discovered.
- It would be good if there was a more dynamic way than hand-writing XRDS documents
- Do a dynamic config/registry example (Jim will do)
- It would be good if there was a more dynamic way than hand-writing XRDS documents
- Need dynamic discovery of what can go into a configuration
- An IGF identity stack could consist of a stub that uses Apache license
- Can use Higgins or other stack to provide services to that stub
- Reviewed http://www.openliberty.org/wiki/index.php/IGF_Architecture#Servlet_Application
- From an application's POV, all data looks the same whether pushed (i.e. incoming token), or pulled (i.e. backend data source)
- Application Services stack could be used like a security provider and shared across different applications
- Talked about providers that can join other providers
- Phil is thinking everything from Caching & Optimization down from http://www.openliberty.org/wiki/uploads//0/0c/Arch-Servlet.gif could be done in Higgins.
- Tom: What does the Caching & Optimization layer do?
- Can analyze incoming operations (like CARML statements) and do things like prefetch (which may consist of multiple underlying operations) data and store it in mem.
- Routing layer can handle things that the existing IdAS registry does, but can also deal with mapping -- though maybe that should be done by a mapping provider?
- Jim: when are the CARML statements passed?
- There can be a CARML declaration passed at a preconfig time, can be sent as a separate file up front which can be reviewed by an auditor,
- Up front stuff can declare what the client app expects to do/see in terms of operations, schema, etc.
- Could also have CARML declarations associated with a transaction (like NewUserRegistration)
- There can be a CARML declaration passed at a preconfig time, can be sent as a separate file up front which can be reviewed by an auditor,
- AAPML data can be returned to express things like:
- Partial data was returned, and here's why
- Data exists, but consent is needed before it's released
- Talked about how IdAS can be extended to handle the passing of CARML and AAPML policy data
- Revive thread on API extensibility (Jim will do)
- Fix jspolicy cp so it will compile (Jim, Tom, or Duane will do)
