On Thu, Sep 12, 2013 at 2:34 PM, Bruno Oliveira <bruno@abstractj.org> wrote:

I couldn't agree more with you Dan and I think that "Camel & Friends"
was supposed to be done by the team responsible for it, in other worlds
Camel team.

To me is clear as crystal that our job is to improve the experience with
mobile like we did with SimplePush, UnifiedPush...etc.

yeah, same feelings here;

I think the integration with "Camel & Friends" came up, during the Face2Face, when looking for UP/SP integration w/ the controller

(I guess that's when Camel integration for the controller came up as well (or was shown)

-M

 

We are not an integration platform as far as I know. (I can be wrong)

> Daniel Bevenius <mailto:daniel.bevenius@gmail.com>
> September 12, 2013 2:30 AM

> >Think "Apache Camel & friends"
> Are we still talking about a "Mobil Gateway" [1] and to have a "no
> code" solution for developers to use?
>
> I've been looking at this previously, and I'm having a hard time to
> understand who would really use something like this for anything
> except a simple demo. It would be a different matter if we were going
> to provided BaaS (Backend as a Service) as we would have more control
> of the backend and could add features in a reliable way (paging,
> security etc). If our Mobil Gateway is simply acting as a intercepting
> proxy it would be more complicated to add such features, and this
> added complexity might introduce other issue with regard to
> connectivity and performance.
>
> If our goal is to enable enterprise services to be exposed to mobile
> devices then I think the simplest option for me would be to add a
> RESTFul interface to those services. This can already be done with
> Camel, SwitchYard, Vert.x, or by using RestEasy. I would think that a
> developer tasked with this would want to follow "normal" development
> practises, using standard development tools, testing, deployment model
> etc,  and not use a web interface perform these task. We could provide
> all that via the GUI, but my guess would be that developers would
> choose the standard way just the same.
>
> [1] https://gist.github.com/danbev/717759ef7a445c626f25
>
>
>

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

> Corinne Krych <mailto:corinnekrych@gmail.com>
> September 11, 2013 11:50 AM

> EIP
>
> to stay cryptic :)
>
> Thanks Doug for this light.
>
> ++
> Corinne
>

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

> Douglas Campos <mailto:qmx@qmx.me>
> September 11, 2013 11:40 AM

>
> Think "Apache Camel & friends" :P
>

> Sebastien Blanc <mailto:scm.blanc@gmail.com>
> September 10, 2013 3:48 AM

> What does the "integration functionality" exactly stands for ?
>
>
>
>

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

> Douglas Campos <mailto:qmx@qmx.me>
> September 10, 2013 2:01 AM

> Howdy!
>
> According to yesterday's team meeting, we need to update our Grand
> RoadMap[1].
>
> Things to note:
>
> - We know the schedule will slip, because push - we just need to
> estimate accordingly.
> - IMHO Security will need a little bit more room than the aggressive
> 6-week cycle - my shoot is 8-week minimum.
> - What about the showcase app? Does it have more priority than the
> "integration functionality?"
> - Offline/Sync: To do it together or not, that's the question!
>
> Let's discuss this RoadMap during this week so we can just agree on the
> outcome at our next team's meeting, **next monday**. I know timing is
> tight but Jay needs this...
>
> Thanks y'all!
>
> [1]:https://github.com/aerogear/aerogear.org/blob/master/docs/scratchpad/AeroGear20RoadMap.markdown
>

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

--
abstractj



_______________________________________________
aerogear-dev mailing list
aerogear-dev@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

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev