Hi, as discussed on IRC, I agree that the "add *" methods are getting a bit overloaded as more options are getting added. Let's revisit this, think about it and discuss the options after we do Alpha1 next week. Thanks, Christos On 15 Οκτ 2012, at 5:36 μ.μ., Matthias Wessendorf wrote: > Hi, > > in order to use the 'auth module' to access protected resources (after > login...) we (somehow) need to pass the AGAuthenticationModule object > into the pipe, when creating it. There are several ways to do that.... > > Today I played around with the idea of using the builder pattern (see > [1]), or going with some (as varargs) 'PipeOption's (see [2]). The > builder pattern looks ugly, due to deep nested calls (from [1]): > > id<AGPipe> tasksPipe = [[[[myPipeline newPipe] > withName:@"logicalName"] withEnpoint:@"tasks" ] buildAndAdd]; > > The 'Options' approach may look a bit more natural for iOS folks, but > to be honest, I don't want to rush on this API rewrite, especially > since we are just one week away from the first (Alphpa1) release of > the iOS lib.... > > = Proposal = > > For passing in the AGAuthenticationModule, I leverage our CURRENT > 'add' approach on the AGPipeline class...... > > However, for the next release (December timeframe), I want to see what > the best options are to get a new 'AGPipeline API' (=> builder VS. > Options VS Config-Object (similar to what our JavaScript API does) VS > ???). Hopefully we can come up with a nice 'DSL' or something like > that which allows an elegant and flexible solution for creating AGPipe > objects.... > > I will update the release roadmap, that for the next release we do > want to spend some time to get rid of the 'add' approach..... That > gives us some more time to DEEPLY think about it. Also since we are > just on Alpha1, it is IMO not a big deal to change the API > afterwards... > > However, if we/I would rush..., I do see the following risks: > - not having security in Alpha1 > - another API rewrite due to a rushed API 'design' > > IMO having the security _functionality_ in there is a bit of higher > interest, instead of have a CLEAN and STABLE API already in Alpha1.... > I know that API changes are awful, but... honestly... there aren't > much users yet and I just don't want to rush for an API, without doing > several prototypes etc. Hence I am moving that API rewrite to the > December timeframe release. > > > Cheers! > Matthias > > [1] https://gist.github.com/3892038 > [2] https://gist.github.com/3892384 > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev