Post Lyons Dream/Deki wishlist
Biggest impediments to going more separate services instead monolithic deki
Service location & access permissions
Right now Deki start-up, starts up a lot of child services instead of having them start themselves up. The primary reason for this is that there is no good way for services to find an existing instance of a service they need to talk to. Deki acts as the injector starting services in order and passing their uri's and cookies to the services that need access to them.
If services could declare named services to be injected at start-up, along with the appropriate cookies or keys, then service decoupling would become significantly easier
User Impersonation
Most permissioning beyond access to a service is done based on the current user. Currently, monolithic deki has the user information set up at request start, however decoupled services have to call deki/users/current and pass along the request headers they received in order for this to work. There is an implicit assumption that the request headers will have the right information for passing this along, which becomes more brittle with more chaining of decoupled services (only one has to do something without the user context for the chain to fail)
In addition, this methodology of impersonation only works as long as work is done in the context of a request. I.e. any queued or asynchronous work loses the impersonation context.
Service to Service call Performance
In order for decoupling to get to the level where Deki is truly a document driven service, service to service calls (at least when local) need to get a lot closer to method calls in efficiency. This may mean that a the request information from the original outside request travels along with local requests rather than be rebuilt or that other method of taking shorter code paths that don't treat the request as a full call from an outside http client.
Dream
- Service Locator (i.e. finding instances by some instance name)
- Dependency injection
- Be able to specify dependent services by SID or instance name as a start requiredment
- Dependency resolution that can determine service startup order to meet declared dependency needs
- Circular dependency resolution (i.e. creation/start separation already does this, might need some warnings about calling dependencies during start since that would result in non-deterministic behavior
- New auth system for better granular access
- Ability to grant rights per calling service
- Ability to grant finer grained rights (maybe per feature? maybe per verb)
- Ability to have auth that survives restart
- New Feature signatures (in addition to existing one)
- Use feature signature for parameter injection
- Interfaced version of DreamContext (including interfaced versions of its dependencies where dependencies aren't just data classes)
- Hierarchical Storage Solution
- Xml-DB?
- Pseudo Xml-Db using file path as document path?
- Per feature call cache with definable caching criteria
- marking what parameters and headers define a unique cache key
- per feature cache expiration rules
- events for downstream services to notify dependencies of cache invalidations
- Tuning Local:// service call efficiency
- Really just a dependent analysis that is likely to be required for the below Deki changes to be feasible
Deki
- Death to DekiContext
- Split up Deki into independent services that call each other for dependencies
- DekiInstance becomes an injected plug to a service responsible the instance data
- Only entity specific services call the DB, everything else is cross service calls, all data is Xml
- Xmpp based Page Alerts
- Maybe just as IMs
- Maybe using Xmpp PubSub to create a Deki Hosepipe
- Tag page
- What links here
| Images 0 | ||
|---|---|---|
| No images to display in the gallery. |
Copyright © 2011 MindTouch, Inc. Powered by