I have some stuff I did on the plane from Summit. I'm going to go back over it tomorrow and see if I included everything I wanted. I'll send the diff to the list.
Sent from my iPhone On Jul 1, 2012, at 9:43, Boleslaw Dawidowicz <[email protected]> wrote: > I think it all comes down (again) to use cases [0] which we think this API > should address. Current ones are mainly around typical web application > development and proposed API prototype was focusing on easy usage. My main > fear is to go end up with too abstract and generic design that won't be > really appealing to most of developers. If you look at use cases addressed by > JSR 351 [1] it is all about dealing with attributes and scenarios closer to > healthcare - and this so far results in quite different API design. API which > I believe will be less appealing to typical web developer who doesn't care > about such use cases. > > More inline below > > [0] > https://cwiki.apache.org/confluence/display/DeltaSpike/Security+Module+Drafts > [1] http://java.net/projects/identity-api-spec/pages/UseCases > > On Jun 29, 2012, at 4:56 PM, Jason Porter wrote: > >> == Security IDM prototype feedback == >> >> * Fold PermissionQuery into PermissionManager to give the developers a >> similar model as JPA. >> >> * Because a Group is an IdentityType, I wonder if it would be better to >> just have one set of methods and pass in the IdentityType sub interface you >> would like to receive back > > I guess thats a bit matter of taste. We could prepare quick prototype and > compare which one looks more useful to majority of folks here. > >> >> * I feel the methods on UserQuery are restricting how the IDM can be used. >> We can't always guarantee that there will be a first name, last name, >> email, etc. However, being completely open and free form like what was done >> in the PicketLink IDM is too much. Perhaps we can find some sort of balance >> or meta model similar to JPA? >> >> * Maybe we could have a base no method interface for things and fold all >> the Query and Manager objects into one (similar to above about JPA) >> >> * We probably don't want to go down the route of create a query language, >> but we almost have a DSL with a fluent API here. Maybe we should think >> about about JPA the names out a bit more and actually create a fluent API >> for the Query objects > > Would you have time to prepare some simple prototype like this to discuss? > I'm not sure how much generic design are you proposing in fact. Just some > bare code snippets would do to back your suggestions with some example usage. > > UserQuery is not something I'm perfectly satisfied with however it is still > an attempt to have something similar to JPA Criteria Query - which is very > intuitive and easy to use IMO. I would love to see more feedback from others > on how to improve this part in fact. > >> >> * I believe we should remove some of the exception constructors and make a >> message required (this would probably be good to have in all of >> DeltaSpike). Adding a cause is great, but being able to create an exception >> without a message is less helpful for everyone. > > Good point. I think this part is simply not really polished yet. > >> >> * Is there a point for having addObject and addObjects type methods? Would >> one that's simply a varag be enough? We could check the type that comes in >> if thy send us a collection, or simply have varags and collection >> addObjects methods. > > Sounds good to me. Again this is probably more matter of taste and > consistency with other APIs in the project. Maybe there should be some > general project wide design guideline for choices like this. > > >> >> >> -- >> Jason Porter >> http://lightguard-jp.blogspot.com >> http://twitter.com/lightguardjp >> >> Software Engineer >> Open Source Advocate >> Author of Seam Catch - Next Generation Java Exception Handling >> >> PGP key id: 926CCFF5 >> PGP key available at: keyserver.net, pgp.mit.edu >
