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

[Matthias Wessendorf]

great - I think the same is true for datamanager, added the API change
to the roadmap for next release.

-M

On Mon, Oct 15, 2012 at 5:43 PM, Christos Vasilakis <cvasilak at gmail.com> wrote:
> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf