[aerogear-dev] [iOS] Proposal Passing 'Auth Module' into pipe.

Matthias Wessendorf matzew at apache.org
Mon Oct 15 10:36:03 EDT 2012


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


More information about the aerogear-dev mailing list