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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Matthias Wessendorf
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

cvasilak
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> 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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev