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? >> 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. Greetings, Marcel _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
