deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Porter <lightguard...@gmail.com>
Subject Re: Early security IDM prototype feedback
Date Mon, 02 Jul 2012 16:20:27 GMT
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 <lightguard.jp@gmail.com>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 <
> boleslaw.dawidowicz@gmail.com> 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

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message