Naming the project
Hi all, Thanks for your input regarding re-naming the project. This came to a draw between Loop and Archway and we decided that Loop is a good name for the WebRTC application project (the product name will be different). Loop is concise, fits all of Andreas requirements and can be turned into a verb just like you do with Skype (Loop me in). So please use "Loop" to name the project moving forward - a Wiki using the Loop name will be created and I'll be in touch with some of you to get that going. If you see any issues with it please let me know! Romain ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: WebRTC Service: On temporary call URLs
Adam, thanks for starting this discussion,
Le 20/02/2014 04:52, Adam Roach a écrit :
> Putting this together, what we want is something that semantically
> evaluates to:
>
> http://authority/action/url-format-version/{serial
> #,caller,callee,expiration,hmac}
As Martin points out, URLs should not represent actions, they should
represent things.
On the experiment we made with Romain Gauthier and Nicolas Perriault, we
went ahead and chose the following scheme:
# A "*" means this URI requires authentication (a valid token from the token
server,
# which contains user id).
* POST /call-url/ → Create the call url a callee can click on.
GET /calls/{token} → Get the app (that's the url in question, which
displays an app)
POST /calls/{token} → Add an incoming call (does a simple push notif
and gets room tokens)
* GET /calls/ → List incoming calls for the authenticated user.
{token} was something that is containing the user id of the callee plus
a . I don't understand why we're trying to put information about the
caller here, since we don't know who is this.
In your proposal, I don't understand what is the "serial #", and
especially why it can't replace the version as you specify it.
It seems straightforward to just have a serial number (randomly
generated and not auto incremented, because auto increment is harder to
scale) that we can revoke if needed.
It means that before displaying the app and accepting a call (we can
also chose one of them only), we will have to check in the database if
this serial # is still a valid one.
We could let the user chose what's the duration of their call-url, and
default to something specified in a configuration file if the user don't
specify anything.
> Ideally, we also want the ability to identify multiple versions of URL
> encodings, should we decide to migrate to include an enhanced scheme
> in the future.
If you're thinking about having multiple versions of the service running
at once, then I think this shouldn't be handled this way. When you ask
for a node to the token server, you ask for a particular version of the
service, and you get an endpoint to this service.
This allows us to not have to deal with multiple versions of the API in
the server code. If that's not what you're refering to, can you provide
more info?
— Alexis
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
User Stories now enabled for "Talkilla" (aka Loop) product in Bugzilla
As of this morning, the "Talkilla"* product now has the User Stories extension added to it in Bugzilla. The extension provides: * A User Story field just under the attachments box * The User story field can be updated by anyone * History is kept for the user story field The intention is that the User story field is the Canonical description of the bug - as we define and flesh out the bug the field can be updated to provide exactly what the bug is about, without needing to go through all the comments. For those that worked on Talkilla, this is exactly the same as how we used the description field on Trello. Mark * Talkilla as that's what we're using. We'll need to get this renamed at some stage (and/or move components to various other locations like FF desktop etc) smime.p7s Description: S/MIME Cryptographic Signature ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: webrtc constraints
Any progress on bandwidth/webrtc constraints control in firefox yet?
On Thursday, July 4, 2013 1:48:12 AM UTC+2, bryand...@gmail.com wrote:
> FF 22 does not seem to honor the video constraints passed to getUserMedia:
>
>
>
> getUserMedia(
>
> {audio:true,video:{mandatory:{maxWidth:320,maxHeight:240}}}
>
> ,gotStream
>
> ,noStream);
>
>
>
> Also, the b=AS:xxx that I put into the offer SDP for audio and video seems
>
> to have no effect at limiting bandwidth,
>
>
>
> Is there any way to limit resolution, frame rate and bandwidth in Firefox's
>
> WebRTC?
>
>
>
> Thanks
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
Github PRs - Bugzilla & Reviews
On 19/02/2014 23:48, Eric Rescorla wrote: > On Wed, Feb 19, 2014 at 3:31 PM, Adam Roach wrote: >> * We will use github pull requests to ensure that patches are reviewed >>prior to landing. >> > > I missed this decision, but it's not really matching what I would have > expected. > > Rather, I would have expected that every patch would correspond to > a bugzilla bug, that we would do reviews in bugzilla, and github pushes > would come with r= as we do now... We discussed it briefly and said that pull requests would correspond to bugs, and when we commit, we can put in r=, plus the bug number. There's a webhook we can then enable, that will automatically post to the bug and even close the bug if we want to (see snippet below). For the reviews, for the server side code that would reside in github, we indicated that doing reviews direct on the github PRs would be fine. Personally I think the main requirement here is that we have proper review, and that it is linked to the appropriate bug i.e. traceable. I think we should use whatever mechanism we find appropriate/easiest to handle those reviews. Obviously for Firefox code, we'll need to follow the normal bugzilla + patch + review mechanism, regardless of whether mercurial or git are used. Mark. = Start Bugzilla githook information = This service hook posts comments on Bugzilla bugs when commit messages reference a bug by id number. Bugs are recognised by the following formats, which are case-insensitive: Ticket 123 Bug 123 Tracker item 123 Multiple bugs can also be specified by separating them with a comma, apersand, plus or "and": Bug 123, 124 and 125 If the "Integration Branch" option is filled in, only commits to that branch will result in bugs being modified. This is useful for disabling premature bug closing/comments when working on feature branches. If "Integration Branch" is not set, commits to all branches will be processed. If you only want to update Bugzilla when you push to your "main" branch: you probably want to set this to "master". If the central repository option is enabled and there is a "fix", "close", or "address" before the bug then that bug is closed. If a commit has already been mentioned in the bug comments when pushed by another user then a comment isn't made, unless the central repository option is enabled. In this case only the first line of the commit message is included in the bug comment. This hook requires Bugzilla version >= 3.4 to function correctly and >= 4.0 to be able to close bugs. = End Bugzilla githook information = smime.p7s Description: S/MIME Cryptographic Signature ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: WebRTC Service: On temporary call URLs
On 2/20/14 04:54, Alexis Métaireau wrote:
Adam, thanks for starting this discussion,
Le 20/02/2014 04:52, Adam Roach a écrit :
Putting this together, what we want is something that semantically
evaluates to:
http://authority/action/url-format-version/{serial
#,caller,callee,expiration,hmac}
As Martin points out, URLs should not represent actions, they should
represent things.
Sure, for most of the HTTP interactions, this is true, and it's a good
principle in general. The way I was viewing this was that the handed-out
call URLs (unlike other operations we're performing) weren't going to be
idempotent: accessing the resource twice would create two calls. In
traditional HTTP design, this would typically be relegated to something
like POST, but we can't pass around URLs with an embedded method in a
well-supported way.
That said, I see that the GET/POST proposal you have addresses this in a
more resource-based fashion, and agree that it's a cleaner way to handle
URLs.
On the experiment we made with Romain Gauthier and Nicolas Perriault, we
went ahead and chose the following scheme...
# A "*" means this URI requires authentication (a valid token from the token
server,
# which contains user id).
* POST /call-url/ → Create the call url a callee can click on.
GET /calls/{token} → Get the app (that's the url in question, which
displays an app)
POST /calls/{token} → Add an incoming call (does a simple push notif
and gets room tokens)
* GET /calls/ → List incoming calls for the authenticated user.
{token} was something that is containing the user id of the callee plus
a . I don't understand why we're trying to put information about the
caller here, since we don't know who is this.
Keep in mind that the nominal user experience for this, once we get to
MVP, will be rooted in an address book. I'll have my list of contacts,
which includes phone numbers and email addresses. When an address book
user is activated by a user, we'll check whether the contact info
corresponds to a Loop user. If so, we place a call in that direction;
otherwise, we offer to create a "call me" URL and (if possible) deliver
it using the contact means (email or phone/SMS) corresponding to the
address book entry. So, when we create the URL, we'll know who the user
intends to give it to.
This is important because it allows us to say "You have an incoming call
from Alexis" rather than "You have an incoming call from some random
person." The delivery of calling party identity is simply considered
table stakes for a communications service nowadays [1].
In your proposal, I don't understand what is the "serial #", and
especially why it can't replace the version as you specify it.
The "serial number" is different for each and every URL issued, and is
used for revocation purposes.
The "version" allows us to transition between schemes in the future, if
we need to change the properties of the URL -- it allows us to
unambiguously change the format of the {token} [2]. For example, if we
decide to re-key the HMAC, we can increase the version number. The same
goes if we decide to add fields, encode them differently, or even go to
a completely different design (such as a sparse key into a database
table). It gives us an "out" to reconsider the design of the token if it
doesn't meet future needs.
It seems straightforward to just have a serial number (randomly
generated and not auto incremented, because auto increment is harder to
scale) that we can revoke if needed.
Sure, random would work, as long as we have sufficiently low chance of
collision. It would be a pretty big error if revocation of one URL
caused a different URL to also be revoked because they shared the same
random identifier.
It means that before displaying the app and accepting a call (we can
also chose one of them only), we will have to check in the database if
this serial # is still a valid one.
If I understand you correctly, you're describing an intended feature of
the system, not a problem: the check for revocation of a serial # is
part of the revocation mechanism.
We could let the user chose what's the duration of their call-url, and
default to something specified in a configuration file if the user don't
specify anything.
Right, that's the intention.
Ideally, we also want the ability to identify multiple versions of URL
encodings, should we decide to migrate to include an enhanced scheme
in the future.
If you're thinking about having multiple versions of the service running
at once, then I think this shouldn't be handled this way. When you ask
for a node to the token server, you ask for a particular version of the
service, and you get an endpoint to this service.
This allows us to not have to deal with multiple versions of the API in
the server code. If that's not what you're refering to, can you provide
more info?
It's not multiple ver
Re: Naming the project
I think that this fails one of the basic criterion that Andreas laid out. Namely, that it can very easily be mistaken for a product name. I can imagine taking this to a public announcement. On 2014-02-20, at 00:57, Romain Testard wrote: > Hi all, > > Thanks for your input regarding re-naming the project. > This came to a draw between Loop and Archway and we decided that Loop is a > good name for the WebRTC application project (the product name will be > different). > Loop is concise, fits all of Andreas requirements and can be turned into a > verb just like you do with Skype (Loop me in). > > So please use "Loop" to name the project moving forward - a Wiki using the > Loop name will be created and I'll be in touch with some of you to get that > going. > > If you see any issues with it please let me know! > > Romain > ___ > dev-media mailing list > dev-media@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-media ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: Architecture Decisions and Action Items for User-Facing WebRTC Project
On Thursday, February 20, 2014 12:31:53 AM UTC+1, Adam Roach wrote: > * L: *Nicolas* to examine use of client libraries (jQuery, Backbone) > to determine how much effort we're likely to save versus the effort > of ensuring we can run the libraries safely in the context of > elevated privileges. So I've started a pad on this here https://webrtc-apps.etherpad.mozilla.org/109 It's in markdown format and is a bit more comfortably readable as rendered html here (frozen state): https://www.dropbox.com/s/9zmz82hemwrf6eo/frontend-engineering.md Any feedback, thoughts are welcome. ++ -- Nicolas Perriault ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: Naming the project
Hi all, I would say that *if* the majority of the team agreed to this, let's move forward with this name. I know it's unlikely we're going to have everyone happy with a project name. The point of 'it could be a product name' is very subjective given some very strange startup product names out there that I would clearly thought were internal names. :) Chris On Feb 20, 2014, at 9:33 AM, Martin Thomson wrote: > I think that this fails one of the basic criterion that Andreas laid out. > Namely, that it can very easily be mistaken for a product name. I can > imagine taking this to a public announcement. > > On 2014-02-20, at 00:57, Romain Testard wrote: > >> Hi all, >> >> Thanks for your input regarding re-naming the project. >> This came to a draw between Loop and Archway and we decided that Loop is a >> good name for the WebRTC application project (the product name will be >> different). >> Loop is concise, fits all of Andreas requirements and can be turned into a >> verb just like you do with Skype (Loop me in). >> >> So please use "Loop" to name the project moving forward - a Wiki using the >> Loop name will be created and I'll be in touch with some of you to get that >> going. >> >> If you see any issues with it please let me know! >> >> Romain >> ___ >> dev-media mailing list >> dev-media@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-media > ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: Naming the project
You know, we might be able to have our cake and eat it too. Just call it PTS, and pretend it is an acronym. Byron On 2/20/14 9:55 AM, Christopher Lee wrote: Hi all, I would say that *if* the majority of the team agreed to this, let's move forward with this name. I know it's unlikely we're going to have everyone happy with a project name. The point of 'it could be a product name' is very subjective given some very strange startup product names out there that I would clearly thought were internal names. :) Chris On Feb 20, 2014, at 9:33 AM, Martin Thomson wrote: I think that this fails one of the basic criterion that Andreas laid out. Namely, that it can very easily be mistaken for a product name. I can imagine taking this to a public announcement. On 2014-02-20, at 00:57, Romain Testard wrote: Hi all, Thanks for your input regarding re-naming the project. This came to a draw between Loop and Archway and we decided that Loop is a good name for the WebRTC application project (the product name will be different). Loop is concise, fits all of Andreas requirements and can be turned into a verb just like you do with Skype (Loop me in). So please use "Loop" to name the project moving forward - a Wiki using the Loop name will be created and I'll be in touch with some of you to get that going. If you see any issues with it please let me know! Romain ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: WebRTC Service: On temporary call URLs
On Thu Feb 20 09:15:15 2014, Adam Roach wrote:
Keep in mind that the nominal user experience for this, once we get to
MVP, will be rooted in an address book. I'll have my list of contacts,
which includes phone numbers and email addresses. When an address book
user is activated by a user, we'll check whether the contact info
corresponds to a Loop user. If so, we place a call in that direction;
otherwise, we offer to create a "call me" URL and (if possible)
deliver it using the contact means (email or phone/SMS) corresponding
to the address book entry. So, when we create the URL, we'll know who
the user intends to give it to.
This is important because it allows us to say "You have an incoming
call from Alexis" rather than "You have an incoming call from some
random person." The delivery of calling party identity is simply
considered table stakes for a communications service nowadays [1].
I'm confused. Isn't the main use case for the "call me link" making it
very easy for someone
who doesn't already have an account to become engaged enough with our
tool that they will be interested in upgrading to get an account to get
the better user experience you're describing?
Otherwise how do we expect to convince enough people to bother to
create a Firefox account, given that the network benefits (i.e. the
systems that all your contacts are already reachable on) have already
accrued in other systems that are believed to be relatively well-liked
(viz Skype, mobile phone)?
Dan
In your proposal, I don't understand what is the "serial #", and
especially why it can't replace the version as you specify it.
The "serial number" is different for each and every URL issued, and is
used for revocation purposes.
The "version" allows us to transition between schemes in the future,
if we need to change the properties of the URL -- it allows us to
unambiguously change the format of the {token} [2]. For example, if we
decide to re-key the HMAC, we can increase the version number. The
same goes if we decide to add fields, encode them differently, or even
go to a completely different design (such as a sparse key into a
database table). It gives us an "out" to reconsider the design of the
token if it doesn't meet future needs.
It seems straightforward to just have a serial number (randomly
generated and not auto incremented, because auto increment is harder to
scale) that we can revoke if needed.
Sure, random would work, as long as we have sufficiently low chance of
collision. It would be a pretty big error if revocation of one URL
caused a different URL to also be revoked because they shared the same
random identifier.
It means that before displaying the app and accepting a call (we can
also chose one of them only), we will have to check in the database if
this serial # is still a valid one.
If I understand you correctly, you're describing an intended feature
of the system, not a problem: the check for revocation of a serial #
is part of the revocation mechanism.
We could let the user chose what's the duration of their call-url, and
default to something specified in a configuration file if the user don't
specify anything.
Right, that's the intention.
Ideally, we also want the ability to identify multiple versions of URL
encodings, should we decide to migrate to include an enhanced scheme
in the future.
If you're thinking about having multiple versions of the service running
at once, then I think this shouldn't be handled this way. When you ask
for a node to the token server, you ask for a particular version of the
service, and you get an endpoint to this service.
This allows us to not have to deal with multiple versions of the API in
the server code. If that's not what you're refering to, can you provide
more info?
It's not multiple versions of the application; it's multiple versions
of the URL field format. At any given moment, any single version of
the server application running would be expected to be able to parse
the current URL format, plus any of the previous URL formats that have
been issued within the ${max_url_duration} seconds.
Yes, this requires some conditional logic in the server code when (if)
we decide to change to change the token format, but that should be
pretty lightweight.
[1] cf.
http://pimcore-1872623517.us-east-1.elb.amazonaws.com/infoservices/resources/whitepapers/whats-next-in-caller-identification-services#.UwYya8dn9N0
[2] Since the current plan is for all tokens to be time-bounded with a
known maximum possible duration, the general means of transitioning
from token format "n" to token format "n+1" would be to introduce the
new format on the new version number; have both formats running
side-by-side for this maximum possible duration; and then retire
format "n" altogether.
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
Re: WebRTC Service: On temporary call URLs
On 2/20/14 12:08, Dan Mosedale wrote: On Thu Feb 20 09:15:15 2014, Adam Roach wrote: Keep in mind that the nominal user experience for this, once we get to MVP, will be rooted in an address book. I'll have my list of contacts, which includes phone numbers and email addresses. When an address book user is activated by a user, we'll check whether the contact info corresponds to a Loop user. If so, we place a call in that direction; otherwise, we offer to create a "call me" URL and (if possible) deliver it using the contact means (email or phone/SMS) corresponding to the address book entry. So, when we create the URL, we'll know who the user intends to give it to. This is important because it allows us to say "You have an incoming call from Alexis" rather than "You have an incoming call from some random person." The delivery of calling party identity is simply considered table stakes for a communications service nowadays [1]. I'm confused. Isn't the main use case for the "call me link" making it very easy for someone who doesn't already have an account to become engaged enough with our tool that they will be interested in upgrading to get an account to get the better user experience you're describing? The "better user experience" you call out *is* for the user with an account, for whom we presumably want as pleasant an experience as possible. The user *without* an account still has to deal with activating the link that has been provided to them. In fact, from the perspective of the user *without* an account, there will be literally zero difference in experience between the system I describe and one without this feature. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
WebRTC service database selection
Looking at database backends for the data we’re talking about storing, these are the ranked concerns that I have heard: 1. availability 2. performance 3. consistency and partition tolerance Basically, if the service is up, that’s good. The data that we are hold here is either very short lived (that related to the push) or easily repaired (device registrations of push URLs). It’s a little more difficult when we get to revocation of URIs, or storing of state for URIs, but I’m going to leave that for a later discussion. The main concern that I have here is service availability in light of data centre failures. In my experience, this happens far more often than is acceptable. For reference, when I was at Skype, Microsoft had numbers that were pretty close to their promise of 99.9% availability. But I need to emphasise this - 99.9% is not good enough for a whole system. 99.99% might be. And the cloud platform is a component of a system, the overall availability will be lower. So geographic distribution of data is critical. This is managed with varying degrees of sophistication by the different storage systems. The biggest part is how they trade off responsiveness and fault recovery. If updating a row requires a cross-geography request, that’s going to be slow, but it means that you get very good failure characteristics. At the same time, it can also mean that you are unable to perform updates in certain types of failure scenario. The key feature - one that most databases provide - is the ability to tune this to application needs. We’re going to want to tune this initially so that updates don’t depend on full replication, since we care more about availability and performance than consistency and partition tolerance. Run-down of options Now, I have only a small amount of background with these specific items unfortunately, my experience is with stuff that I believe some of you might think to be poisonous, plus some stuff we just can’t use. Nonetheless, here are what I believe to be the high runner options: MongoDB This is very widely used, readily deployed to the cloud platform of your choice and it has a pretty good story when it comes to performance. Mongo does have a geographic redundancy story. It’s not covered in glory, but nor is it entirely embarrassing. I’m less encouraged by the characteristics of the geographic redundancy features; replica sets can only be statically configured to prefer local communication, which means that a failure in the local cluster will result in cross-geo operations for all requests that block on replication. I’m also a little concerned about how placement is controlled within a cluster. http://docs.mongodb.org/manual/core/replica-set-architectures/ Cassandra Cassandra is also widely used, with similar characteristics to Mongo. This has a larger number of options with respect to geographic redundancy. The topology aware replication mode offers some pretty good opportunities, particularly when deployed with a “snitch” that is aware of the deployment layout. http://www.datastax.com/documentation/cassandra/1.2/cassandra/architecture/architectureDataDistributeReplication_c.html Redis Redis is probably the simplest option here. Its high availability option is still unstable, so I’m not going to recommend it. Dynamo This would tie us to AWS, but it seems like a capable DB. The problem is that in the short time I looked, I couldn’t uncover any details on their geographic redundancy story. That is not encouraging. Roll your own geo redundancy This remains a viable option…if you really need the performance/availability/other characteristic. Typically you take an existing store (pick one, any one) and you add your own brand of geographic redundancy to suit your needs. This has the advantage of being exactly what you need, but the disadvantage of it being a bunch of extra work. I’m not going to recommend this either; but it’s an option that may become worth considering later, unless our database friend really pick up their collective game. Others I could provide info on memcached(b), Azure, Riak, etc… All of which have their merits, but none of which are really strong contenders for the crown. Summary I think that we could make either Mongo or Cassandra work for us. If we were truly serious about storing hard state, then I think Cassandra offers more control, but I think that it would be a harder challenge from an operational perspective to use and deploy. At this stage, I’m going to suggest that we pick Mongo, even though I think Cassandra might be functionally superior. As long as we create and maintain a good abstraction for our data store, I think that we can switch if needs change. …always create and maintain a good abstraction for stuff like this. ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: Architecture Decisions and Action Items for User-Facing WebRTC Project
On 2/20/14 9:52 AM, nperria...@mozilla.com wrote: On Thursday, February 20, 2014 12:31:53 AM UTC+1, Adam Roach wrote: * L: *Nicolas* to examine use of client libraries (jQuery, Backbone) to determine how much effort we're likely to save versus the effort of ensuring we can run the libraries safely in the context of elevated privileges. So I've started a pad on this here https://webrtc-apps.etherpad.mozilla.org/109 It's in markdown format and is a bit more comfortably readable as rendered html here (frozen state): https://www.dropbox.com/s/9zmz82hemwrf6eo/frontend-engineering.md Any feedback, thoughts are welcome. This is a really helpful analysis; thanks for writing it up! Since we're trying to get a fast start here, rather than trying to have all these discussions at once (and since a number of them are clearly not in the MLP scope), I'd suggest that we start with the highest order bit, which as far as I can tell (both from my gut and from our earlier discussions this week), is the MV* stuff. I talked to Adam a bit about the security context today, and he suggested assuming for now that we're likely to get good enough security code partitioning that we'll have the option of moving forward with Backbone or something like it if that makes sense. My understanding (which may or may not be correct), is that there is no particular framework for B2G apps generally, and that each one does its own thing. The reason I think talking to James is likely a good next step is because I believe he has insight into more than one such Gaia app solution, and he has insight into non-B2G stuff in this space as well. I'd love to try and get the three of us on a call tomorrow if we can make the timing work. I'll send out an email to see if he might be available for such a thing. But feel free to check for him on IRC if he happens to be around before I'm up. (He's often in #gaia as lightsofapollo). I've been told that tofumatt on #webdev has a bunch of experience with backbone on mobile as well, so you might check in with him too. Dan ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
