On 16.08.2017 12:40, Gijs Kruitbosch wrote:
This and other queries like it are best asked and answered on >
https://support.mozilla.org/ .
Unfortunately, it only tells how to switch some things off, but
not to remove it entirely. Neither does it tell anything about the
security implications of sending meta data to dubious corporations.
Furthermore, just like with your > next-most-recent posts (about nsString and printf, and about CIDs),
the > answer is already documented and easily found using a web search:
If the docs wouldn't answer all my questions, I wouldn't have asked in
the first place. I'd volunteer to update the docs, but obviously I need
the proper information for that first.
https://developer.mozilla.org/en-US/search?q=printf
--> nothing about using printf() here :(
Regarding CID vs CONTRACTID - still haven't understood why CIDs are
random numbers, instead of human-readable names (similar to hierarchical
class names, eg. "org.mozilla.collections.array) ?
And still I find the naming "CID" (class-ID ?) vs "CONTRACTID" quite
confusing. Why not something like "INTERFACEID" or "PROTOCOLID" vs.
"SERVICEID" ?
The term "contract" isn't entirely obvious (to non-moz folks), it's
often used for interface (the way I can talk to something), instead
of a collection of interfaces / a service that might have multiple
interface.
I also believe your reflexive responses along the line of "how can I get > a version of Firefox that doesn't have X" for every X (you don't
like) > that happens to come up in this group are unproductive.
This "reflex" comes from the tendency that more and more things are
added - even things that contradict the whole spirit of free software,
like despotic restriction management (even downloads the malware on
its own) - and then we downstreams (packagers, integrators, operators)
have the huge burden of getting these things under control.
Please also consider, that there's more than average John Doe user,
and there're lots of reasons for disabling things (not even compile
them in the first place). Limited resources may be one of them.
Security concerns, managebility, etc, may be others. One's killer
feature can be another one's misfeature. Therefore it's important
that things can be turned off / removed easily (the optimum would
be external components that can be deployed separately).
A bunch of configure options are currently broken, some can't be
easily repaired (w/o touching xpidlgen to add preprocessor).
The answer to that last question is almost invariably "no". There are > usually prefs while features are being developed, but those will >
frequently get removed when features are mature enough that we don't >
think turning them off is web-compatible.
How exactly is "web-compatible" specified here ?
Does it include $megacorp's servers or automatically download
and execute arbitrary binaries or allow tracking users ?
Firefox and Gecko are > explicitly *not* aiming to have 42,000 build-time defines to remove >
every conceivable feature that someone might not want.
Doesn't need to be that much. Less than hundred should be sufficient,
and most of them should be orthogonal to the rest.
--mtx
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
