On Mon, Jan 23, 2012 at 2:01 PM, Robert Kaiser <[hidden email]> wrote:
> Mike Hommey schrieb:
> We already do something like this, except we don't check what is already
>> loaded, we only block further loadings. And that doesn't really require
> I thought I read recently that our DLL blocklist stuff is ineffective when
> dealing with the Windows hooking mechanisms.
It does not cover all of the possible hooking mechanisms, yes. But it does
cover the vast majority of them.
On Fri, Jan 20, 2012 at 1:44 AM, Brian Smith <[hidden email]> wrote:
> AFAICT, there is no such thing as an addon or extension API in B2G at all.
Correct. If it will have one, it will be a Web API that we will be
trying to standardize (cf. bsmedberg's reply). It's important to
understand that in B2G, Gecko is part of the OS. It's not a program
that the user has much control over.
> Every app is to be a regular HTML5 web app, that you will be able to run in the desktop browser too. They will use new web APIs that haven't been standardized (or even created) yet, with some way of handling permissions so that the user can let web apps he/she trusts do things that currently our platform doesn't allow because it is too dangerous to let any web app do them by default.
> Also, keep in mind that in B2G, the user is supposed to be able to replace any built-in app with his own app (except maybe safety-critical things like the dialer). And, ideally, the built-in apps wouldn't have any advantage over user-created apps--in particular, no special access to ANY kind of API (LDAP or otherwise). The best way to ensure that is to have all the built-in apps, including *especially* the default email client, be pure HTML5 apps.
> (I do agree that SMTP/IMAP/POP/LDAP email is a must-have for any serious B2G phone.)
I disagree. There's no reason email delivery can't use HTTP. In fact,
let me say that I will call it a success if B2G will contribute even a
tiny bit to HTTP displacing more of SMTP/IMAP/POP/...
That said, your portrayal of the B2G platform is correct. Apps that
get to run on B2G are essentially websites using web APIs. That means
if there's functionality that isn't covered by a web API yet then it's
our plan to create one and standardize it. I'm skeptical as to whether
that should include new ways of communicating with a web servers, even
if it's to accomodate legacy protocols.
dev-planning mailing list
[hidden email] https://lists.mozilla.org/listinfo/dev-planning