Due to Apache's blanket attachment scrub policy, you can find the same info at my github fork: https://github.com/LightGuard/incubator-deltaspike/commit/d5fc02d0493c2cfe6c46cd4ffc6c786968372d52
On Mon, Jul 2, 2012 at 12:20 PM, Jason Porter <[email protected]>wrote: > Attached is my diff from what I had pulled down as of Wednesday or so. > Feel free to discuss, dissect, etc > > > On Sun, Jul 1, 2012 at 12:49 PM, Jason Porter <[email protected]>wrote: > >> 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 >> > >> > > > > -- > 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 > -- 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
