Great, just created AMDATU-460 to start design and implementation work on this.
On Oct 27, 2011, at 9:33 , Bram de Kruijff wrote: > He Marcel > > On Wed, Oct 26, 2011 at 5:51 PM, Marcel Offermans > <[email protected]> wrote: >> Hello Bram, >> >> On Oct 26, 2011, at 12:21 PM, Bram de Kruijff wrote: >>> 2011/10/25 Marcel Offermans <[email protected]>: >>>> Now that we released Amdatu Platform, we should probably continue this >>>> discussion. >>>> I think the most important thing we need to do, is to figure out what our >>>> Tenant interface should look like, and how we want to configure the >>>> tenants. >>>> Looking at the current Tenant interface, each tenant has an "id" and >>>> "name". >>>> That makes sense. It also has a set of properties, and methods to access >>>> and >>>> modify them. I would propose that we remove the method to modify the >>>> properties (putProperty) and I'm also not sure what the actual use of the >>>> "matches" method is: if you have a method to access the Dictionary of >>>> properties, then you can use the standard OSGi filter mechanism to do >>>> matches (in a more flexible way even). >>>> So I propose we move to this interface: >>>> public interface Tenant { >>>> String getId(); >>>> >>>> String getName(); >>>> >>>> Dictionary getProperties(); >>>> } >>> >>> Mostly agreed. Just a thought/question though... why is Tenant not (or >>> does not extend) org.osgi.service.useradmin.User? Does it not make >>> sense to regard tenants as users (of a specific type) at the platform >>> level, and store them using a well know mechanism with standard >>> interfaces? We could still publish them as Tenant extends User >>> services or whatever to do compatibility. >> >> Going along with that thought, that would mean that we would first install >> an implementation of UserAdmin (optionally plus backend, but probably a file >> based solution is fine for this). Then we would have a bundle that would >> start listening to UserAdmin events, and perhaps filter out the ones that >> are about users that are of the type "tenant". Based on those, it would >> publish these Tenant services (that extend User). It definitely sounds more >> complicated to me. Also, I don't see what all the extra methods that a User >> has would add to our tenant interface. >> >> Furthermore, since I think we agreed before that we do not necessarily want >> CRUD operations for tenants (they are already deprecated in our current API). >> >> All in all, to me at least a tenant has to be identifyable, it probably >> needs a human-readable name and it might require a few properties (mainly >> used in the code that services incoming requests and assigns them to the >> correct tenant). That's all. Do you see this differently? > > Agreed > >>>> Also, I propose we configure the tenants via ConfigurationAdmin, using a >>>> ManagedServiceFactory, requiring at least an ID for each tenant, and >>>> optionally the name. Any other properties will be exposed via >>>> getProperties(). >>> >>> Think so yes. This mapping to ManagedServiceFactory will be trivial to >>> map to Ace configuration files lateron right? >> >> Exactly, so we can provision the tenants lateron. > > So +1 for me > > grz > Bram > >> Greetings, Marcel >> >> >> _______________________________________________ >> Amdatu-developers mailing list >> [email protected] >> http://lists.amdatu.org/mailman/listinfo/amdatu-developers >> > > _______________________________________________ > Amdatu-developers mailing list > [email protected] > http://lists.amdatu.org/mailman/listinfo/amdatu-developers > _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
