<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">I'll let Nikhil remark on the client
side stuff, since that's his area of expertise. <br>
<br>
Looking at the server, I see that you do storage in memory. You
may want to note that in the ReadMe in case some folks start
running this and wonder why their apps need to reregister
frequently. <br>
<br>
One other thing I forgot to mention was that my server also
discards the sent version data. There are a few reasons to do this
(one being that it not only reduces potential security issues, but
also reduces the data storage requirement). Instead, I simply use
UTC for the version. It does mean that there's a risk that an
accidentally malicious server could "flood" their channel with
update requests, but there are ways to deal with that and it's
kind of a corner case.<br>
<br>
Obviously, we'd love more input if you have different opinions
about that.<br>
<br>
On 2013/6/4 9:19 AM, Kris Borchers wrote:<br>
</div>
<blockquote
cite="mid:3E047D59-83E8-4547-90F4-BD632E559425@redhat.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
Great to hear that you guys are interested in collaborating a bit
with us! We are really excited about what we have so far and where
we want to go with this to hopefully help bring SimplePush to the
browser. I have added our developer mailing list to the CC.
<div><br>
</div>
<div>Another repo we wouldn't mind you taking a peek at is the
client side polyfill stuff I have been working on here <a
moz-do-not-send="true"
href="https://github.com/aerogear/aerogear-js/blob/Notifier/src/simple-push/aerogear.simplepush.js">https://github.com/aerogear/aerogear-js/blob/Notifier/src/simple-push/aerogear.simplepush.js</a> and
the bit that does most of the work is here <a
moz-do-not-send="true"
href="https://github.com/aerogear/aerogear-js/blob/Notifier/src/notifier/adapters/simplePush.js">https://github.com/aerogear/aerogear-js/blob/Notifier/src/notifier/adapters/simplePush.js</a>.
It currently lives on a branch for the new Notifier bits I am
adding to AeroGear.js for some API unification for different
messaging protocols. Basically what we are doing is using
websockets (or a fallback) via SockJS and storing some channel
info in localStorage for re-registration, etc.</div>
<div><br>
</div>
<div>Any and all feedback would be appreciated. Even if it's
"You're crazy! Don't do that! Do this!" :)</div>
<div><br>
</div>
<div>Thanks and also excited to be able to work with you on this
as well!</div>
<div><br>
</div>
<div>
<div>
<div>On Jun 4, 2013, at 10:30 AM, JR Conlin <<a
moz-do-not-send="true" href="mailto:jrconlin@mozilla.com">jrconlin@mozilla.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">We have <a moz-do-not-send="true"
href="mailto:push-notifications@mozilla.org">push-notifications@mozilla.org</a>,
however that list is not widely used. I wouldn't mind adding
it as a CC to the discussion, however.<br>
<br>
I'm fine using your public mail list, if you don't mind me
pointing to it from our wiki pages or summarizing discussion
points there.<br>
<br>
Neat, you're implementing a netty version. I'll have to dig
into it and see how you're building that out.<br>
<br>
I should also probably mention that to get things up to
large scale, the go version I built does a few things
different than the strict spec says. <<a
moz-do-not-send="true"
href="https://github.com/jrconlin/pushgo">https://github.com/jrconlin/pushgo</a>><br>
<br>
1. The server doesn't really care that much about valid
channelIDs.<br>
As you know, when you start to have to deal with very large
numbers of connections, you really want to reduce your data
storage dependencies. Since SimplePush is a "best effort"
system (we're not guaranteeing delivery of messages in all
cases since that's prohibitively expensive), we merely
collect channelIDs for a given UAID and report them to the
client on flush. This allows us to not have to do a data
fetch, since the client will discard any unknown channelID,
passing those values to the client does not cause user
facing issues. I can prevent random "griefing" from
malicious users by using a simple AES hash on the endpoint.
If the hash fails to decrypt, I don't even bother trying to
store anything.<br>
<br>
I also don't report back failures to PUT requests. The less
information that I give malicious parties, the better, and
legit parties will always get the same result.<br>
<br>
2. I take advantage of memcache's self expiring records to
auto-prune entries. Legit notifications live for 3 days.
This is based on the idea that notifications tend to be
fairly ephemeral and you probably don't really care if an
accident slowed down your commute home last Thursday.<br>
<br>
We're excited that you want to contribute and look forward
to working with you.<br>
<br>
On 2013/6/4 5:20 AM, Erik Jan de Wit wrote:<br>
<blockquote type="cite">Forgot to add these guys<br>
<br>
Cheers,<br>
Erik Jan<br>
<br>
Begin forwarded message:<br>
<br>
<blockquote type="cite">*From: *Erik Jan de Wit <<a
moz-do-not-send="true"
href="mailto:erikjan.dewit@gmail.com">erikjan.dewit@gmail.com</a><br>
<<a moz-do-not-send="true"
href="mailto:erikjan.dewit@gmail.com">mailto:erikjan.dewit@gmail.com</a>>><br>
*Subject: **Re: Firefox OS App Day*<br>
*Date: *June 4, 2013 8:48:26 AM GMT+02:00<br>
*To: *jr conlin <<a moz-do-not-send="true"
href="mailto:jrconlin@gmail.com">jrconlin@gmail.com</a>
<<a moz-do-not-send="true"
href="mailto:jrconlin@gmail.com">mailto:jrconlin@gmail.com</a>>><br>
*Cc: *Nikhil Marathe <<a moz-do-not-send="true"
href="mailto:nmarathe@mozilla.com">nmarathe@mozilla.com</a><br>
<<a moz-do-not-send="true"
href="mailto:nmarathe@mozilla.com">mailto:nmarathe@mozilla.com</a>>>,
JR Conlin <<a moz-do-not-send="true"
href="mailto:jrconlin+moz@gmail.com">jrconlin+moz@gmail.com</a><br>
<<a moz-do-not-send="true"
href="mailto:jrconlin+moz@gmail.com">mailto:jrconlin+moz@gmail.com</a>>><br>
<br>
Hi,<br>
<br>
Great to hear from you, we are building something based
on the specs<br>
that you wrote. The idea is that this will serve as a
polyfill we have<br>
a server as well<br>
<a moz-do-not-send="true"
href="https://github.com/danbev/aerogear-simplepush-server">https://github.com/danbev/aerogear-simplepush-server</a>
To be able to<br>
stay in sync with what you are doing we need have some
additional<br>
questions is it ok for you to have a discussion on our
public mailing<br>
list?<br>
<br>
Cheers,<br>
Erik Jan<br>
<br>
On Jun 2, 2013, at 8:46 PM, jr conlin <<a
moz-do-not-send="true"
href="mailto:jrconlin@gmail.com">jrconlin@gmail.com</a><br>
<<a moz-do-not-send="true"
href="mailto:jrconlin@gmail.com">mailto:jrconlin@gmail.com</a>>>
wrote:<br>
<br>
<blockquote type="cite">Hi Erik Jan,<br>
<br>
Yes, we're the folks you probably want to talk to.
Nikhil works on<br>
the Client portion (the elements that run on the
device or browser),<br>
and I work on the Server portion.<br>
<br>
We'd love to hear your questions, since we've been
fairly deep into<br>
this for a while and it's always good to have folks
point out the<br>
confusing bits.<br>
<br>
I can tell you that a bunch of the more confusing
elements might go<br>
away if we note that SimplePush isn't supposed to be
100% guaranteed<br>
delivery, but "Best Effort". Doing 100% guaranteed is
very expensive<br>
from a hardware and software point of view and costs
tend to<br>
seriously escalate once you get past a few hundred
users. Instead,<br>
the system tries it's best to send a dataless "ping"
to the device,<br>
in many cases, leaving how the ping actually gets to
the device as a<br>
responsibility of the system that is closest to the
device.<br>
<br>
Think about how email is sent around. Just because you
hit "send"<br>
doesn't mean that the email has appeared at the
destination. Often<br>
it's handed around to multiple systems before finally
making it to<br>
the location.<br>
<br>
In that scenario, "errors" become a bit harder to nail
down. There<br>
are definite errors when a device can't talk to it's
immediate<br>
server, and we try to handle those appropriately.
There are also<br>
potential errors that may happen if an end point tries
to ping a<br>
device that doesn't exist. Where things get fuzzy are
the errors<br>
around a device that just got run over by a bus or sat
in a drawer<br>
with a dead battery for a week.<br>
<br>
In any case, feel free to contact us via email or if
you like on<br>
<a moz-do-not-send="true"
href="http://irc.mozilla.org/#push">irc.mozilla.org/#push</a>
<<a moz-do-not-send="true"
href="http://irc.mozilla.org/#push">http://irc.mozilla.org/#push</a>><br>
<br>
On 6/2/2013 10:10 AM, Henrik 'henx' Mitsch wrote:<br>
<blockquote type="cite">Hi Nikhil and JR,<br>
<br>
looking at <a moz-do-not-send="true"
href="https://wiki.mozilla.org/WebAPI/SimplePush">https://wiki.mozilla.org/WebAPI/SimplePush</a>
you seem to be<br>
the main editors. Last weekend we had a Firefox OS
App Day in<br>
Switzerland. It was awesome!<br>
<br>
Erik Jan was one of the participants. He has a
question concerning<br>
Simple Push (see below). Can you guys help him out?<br>
<br>
Best regards,<br>
Henrik<br>
Mozilla Rep<br>
<br>
<br>
<br>
On 28.05.13 09:59, Erik Jan de Wit wrote:<br>
<blockquote type="cite">Hi Henrik,<br>
<br>
I was talking with my colleges about the nice day
we had saturday.<br>
And I mentioned that you could bring us in contact
with people that<br>
build the Simple Push into Mozilla. Like I've
explained before we<br>
made an implementation as well based off the specs
that are on the<br>
MDN, but would be nice if we could sync with the
one that was<br>
developed for Mozilla OS as the specs have some
holes. For instance<br>
how to handle errors is not really clear. Could
you bring us in<br>
contact with the people that implemented this in
Firefox?<br>
<br>
Thanks, Erik Jan<br>
<br>
</blockquote>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>