7:01 a.m.
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/A...
--
qmx
8:48 a.m.
What does the "integration functionality" exactly stands for ?
On Tue, Sep 10, 2013 at 7:01 AM, Douglas Campos <qmx(a)qmx.me> wrote:
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/Aero...
--
qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:53 a.m.
From the roadmap:
• Simple integration options (basic WS client
work)
Same as Seb, wht is the integration fucntionality, I was also wondering what WS stands
for.
++
Corinne
On Sep 10, 2013, at 8:48 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
What does the "integration functionality" exactly stands
for ?
On Tue, Sep 10, 2013 at 7:01 AM, Douglas Campos <qmx(a)qmx.me> wrote:
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/A...
--
qmx
_______________________________________________
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
11:29 a.m.
same questions
-M
On Tue, Sep 10, 2013 at 8:53 AM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
>From the roadmap:
• Simple integration options (basic WS client work)
Same as Seb, wht is the integration fucntionality, I was also wondering
what WS stands for.
++
Corinne
On Sep 10, 2013, at 8:48 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
> What does the "integration functionality" exactly stands for ?
>
>
>
> On Tue, Sep 10, 2013 at 7:01 AM, Douglas Campos <qmx(a)qmx.me> wrote:
> 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/Aero...
>
> --
> qmx
> _______________________________________________
> 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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
4:50 p.m.
EIP
to stay cryptic :)
Thanks Doug for this light.
++
Corinne
On Sep 11, 2013, at 4:40 PM, Douglas Campos <qmx(a)qmx.me> wrote:
On Tue, Sep 10, 2013 at 08:48:48AM +0200, Sebastien Blanc wrote:
> What does the "integration functionality" exactly stands for ?
Think "Apache Camel & friends" :P
--
qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
7:30 a.m.
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
On 11 September 2013 16:50, Corinne Krych <corinnekrych(a)gmail.com> wrote:
EIP
to stay cryptic :)
Thanks Doug for this light.
++
Corinne
On Sep 11, 2013, at 4:40 PM, Douglas Campos <qmx(a)qmx.me> wrote:
> On Tue, Sep 10, 2013 at 08:48:48AM +0200, Sebastien Blanc wrote:
>> What does the "integration functionality" exactly stands for ?
>
> Think "Apache Camel & friends" :P
>
> --
> qmx
> _______________________________________________
> 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
2:34 p.m.
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.
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(a)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(a)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(a)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/A...
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
2:48 p.m.
On Thu, Sep 12, 2013 at 2:34 PM, Bruno Oliveira <bruno(a)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(a)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(a)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(a)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/Aero...
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
3:22 p.m.
+1
But what we could think about in terms of "integration" is for instance :
- Making a Unified Push Instance "discoverable" by RHQ
- Making a Application that is using the Unified Sender "discoverable" by
RHQ : to be able to configure Push Configuration from a central place (RHQ
plugin ...)
On Thu, Sep 12, 2013 at 2:48 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
On Thu, Sep 12, 2013 at 2:34 PM, Bruno Oliveira <bruno(a)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(a)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(a)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(a)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/Aero...
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> --
> abstractj
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:37 p.m.
On 09/10/2013 01:01 AM, Douglas Campos wrote:
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 are the goals/bullet points we are
trying to hit in security?
- 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!
An additional
question, what are the client side/server side resources
for it?
When I say server side I'm thinking do we make a unified offline/sync
server, do we write some plugins for Hibernate, $babbysFirstORM,
$NoSQLisWebscale, $DataFabricBusOoooOooooMeMePickMe, etc?
Would prefetching also be in scope? That one is always a bitch to get
right but it makes all the difference in the world some time.
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/A...
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:29 p.m.
I can't tell you, wouldn't be safe :)
Summers Pittman wrote:
What are the goals/bullet points we are trying to hit in security?
Security roadmap is up do date but of course, I'm open for suggestions.
See 1.3.0 section:
http://aerogear.org/docs/planning/roadmaps/AeroGearSecurity/
--
abstractj
4:24 p.m.
On 09/12/2013 08:29 AM, Bruno Oliveira wrote:
I can't tell you, wouldn't be safe :)
Summers Pittman wrote:
> What are the goals/bullet points we are trying to hit in security?
Security roadmap is up do date but of course, I'm open for suggestions.
See 1.3.0 section:
http://aerogear.org/docs/planning/roadmaps/AeroGearSecurity/
I see the crypto bits
for android. If we include file system/SQLite
encryption then it dovetails nicely into 1.4 which is
offline/prefetch/etc. However, I don't see any use cases/goals/etc. IE
I'm not sure what implementing crypto will look like. This may be my
problem though
I was wondering, will this be a good time to drag in more enterprise
features like remote wipe, authz, and friends?
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
5:33 p.m.
New subject: Goals on Security
I'm changing the subject because I don't want to hijack that thread.
Summers Pittman wrote:
I see the crypto bits for android. If we include file system/SQLite
encryption then it dovetails nicely into 1.4 which is
offline/prefetch/etc.
+1
However, I don't see any use cases/goals/etc. IE I'm not
sure what
implementing crypto will look like. This may be my problem though
Currently
I'm working to provide easy to use encryption for JS, iOS and
Android (https://github.com/abstractj/cryptoparty). This project aims to
provide: password encryption, symmetric/asymmetric encryption,
hashing...and all the things to mess up with your data. Once I have a
first draft, documentation + the usage and scenarios will be included to
some whatever AeroGear Crypto spec.
(The name of the project will change, or not)
I was just wondering about 2 possible showcase apps:
- Encrypted chat (it creates a dependency on the server side) -1 on it
- Password manager app (do not depend on the server until we start to
discuss data sync) +1
I was wondering, will this be a good time to drag in more enterprise
features like remote wipe, authz, and friends?
I think they are all good features. ATM I would say, let's stay focused
on offline encryption and be more server independent as possible. Also
feel free to send a PR to our security roadmap
(https://github.com/aerogear/aerogear.org/blob/master/docs/planning/roadma...)
I can't guess how many kit kats we want :)
Makes sense?
--
abstractj
5:37 p.m.
New subject: Goals on Security
+1. I'll chat with Passos and get some goals and PR them
Sent from my Android phone using TouchDown (www.nitrodesk.com)
-----Original Message-----
From: Bruno Oliveira [bruno(a)abstractj.org]
Received: Monday, 16 Sep 2013, 11:34AM
To: AeroGear Developer Mailing List [aerogear-dev(a)lists.jboss.org]
Subject: Re: [aerogear-dev] Goals on Security
I'm changing the subject because I don't want to hijack that thread.
Summers Pittman wrote:
I see the crypto bits for android. If we include file system/SQLite
encryption then it dovetails nicely into 1.4 which is
offline/prefetch/etc.
+1
However, I don't see any use cases/goals/etc. IE I'm not
sure what
implementing crypto will look like. This may be my problem though
Currently
I'm working to provide easy to use encryption for JS, iOS and
Android (https://github.com/abstractj/cryptoparty). This project aims to
provide: password encryption, symmetric/asymmetric encryption,
hashing...and all the things to mess up with your data. Once I have a
first draft, documentation + the usage and scenarios will be included to
some whatever AeroGear Crypto spec.
(The name of the project will change, or not)
I was just wondering about 2 possible showcase apps:
- Encrypted chat (it creates a dependency on the server side) -1 on it
- Password manager app (do not depend on the server until we start to
discuss data sync) +1
I was wondering, will this be a good time to drag in more enterprise
features like remote wipe, authz, and friends?
I think they are all good features. ATM I would say, let's stay focused
on offline encryption and be more server independent as possible. Also
feel free to send a PR to our security roadmap
(https://github.com/aerogear/aerogear.org/blob/master/docs/planning/roadma...)
I can't guess how many kit kats we want :)
Makes sense?
--
abstractj
3868
days inactive
3874
days old
15 comments
7 participants
participants (7)
-
Bruno Oliveira -
Corinne Krych -
Daniel Bevenius -
Douglas Campos -
Matthias Wessendorf -
Sebastien Blanc -
Summers Pittman