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
