tag:blogger.com,1999:blog-1015214236289077798.post3968266723153729200..comments2024-03-24T17:13:53.855-07:00Comments on TenFourFox Development: Let's kill kittens with native messaging (or, introducing OverbiteNX: if WebExtensions can't do it, we will)ClassicHasClasshttp://www.blogger.com/profile/17331846076856918359noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-1015214236289077798.post-17182923691423119552018-06-12T21:49:33.419-07:002018-06-12T21:49:33.419-07:00You still aren't making any real sense to me.
...You still aren't making any real sense to me.<br /><br />Why you can't just propose OverbiteNX's "API" as a starter proposal to Mozilla? I mean if it's good enough that you feel others can safely rely on it instead of waiting for Mozilla's rubber-stamp, then why not try that much?<br /><br />You don't have to do anything beyond that if you'd rather not, but it seems like a waste not to try that much at this stage?<br /><br />It honestly just makes it seem like you are unwilling to do what's *truly* necessary right now to get the APIs *you* want into Firefox proper, despite having possibly done almost all of the work already, and despite having real no commitment to follow through.<br /><br />I can't say that's a sympathetic viewpoint when I know that Mozilla are also willing to do the eventual implementation *plus* everything else to get the feature specced-out, once higher-priority APIs are done.<br /><br />Why we should be pressuring Mozilla more and not you? Neither of you are obligated to do the work, but only one seems willing to even try to do it right.BashZeStampeedohttps://www.blogger.com/profile/08974610047844166539noreply@blogger.comtag:blogger.com,1999:blog-1015214236289077798.post-1388883595420583642018-06-10T19:29:37.668-07:002018-06-10T19:29:37.668-07:00They most certainly will have to prioritize expand...They most certainly will have to prioritize expanding the API surface when half the add-ons on AMO eventually depend on components that aren't distributed there.<br /><br />Moreover, I don't determine what's acceptable to Mozilla, and they know what their pain points and limits are. I'm not going to boil the ocean trying to collect everyone else's use case if the idea will never get off the ground administratively. Mozilla needs to say what they're going to allow and not allow, and only they can say that.ClassicHasClasshttps://www.blogger.com/profile/17331846076856918359noreply@blogger.comtag:blogger.com,1999:blog-1015214236289077798.post-43819556082147932382018-06-10T17:07:28.830-07:002018-06-10T17:07:28.830-07:00First things first: know that I truly respect you ...First things first: know that I truly respect you and your work (otherwise I wouldn't bother writing this in the first place). I just hate the thought that you'd waste your valuable time on something self-defeating. After all, this work proves that Mozilla don't have to prioritize a socket API over other things, because OverbiteNX now exists, all using WebExtensions as they're meant to be used.<br /><br />Now maybe this was just intended as a precursor to a true API proposal, at which point I apologize (that didn't come across to me in your post). But if it's not, then you're not showing a willingness to do the currently-necessary work, which is what matters now. Fair enough, but then just applying more pressure on the few people who *are* willing to do it, but are already overburdened, won't help. They're humans, not steam engines.BashZeStampeedohttps://www.blogger.com/profile/08974610047844166539noreply@blogger.comtag:blogger.com,1999:blog-1015214236289077798.post-74661904824573425832018-06-09T23:58:24.775-07:002018-06-09T23:58:24.775-07:00I'm trying to be polite here, but did you actu...I'm trying to be polite here, but did you actually RTFA?<br /><br />I actually *am* willing to write the implementation, but Mozilla is going to have to say what they're willing to accept. They haven't, and they haven't made really any progress on writing the spec, which *they* have to do. I'm not working my ass off to write code that has no chance of ever being used. I've done that before and I'm not doing it again.<br /><br />It's not supposed to be a long-term idea, either. I think I made that clear. But it's going to be what gets the project off the ground. And pressure is definitely needed to get Mozilla(tm) collectively thinking about what they're willing to tolerate so that, yes, people can actually write it. That hasn't happened.ClassicHasClasshttps://www.blogger.com/profile/17331846076856918359noreply@blogger.comtag:blogger.com,1999:blog-1015214236289077798.post-60348156886800146222018-06-09T21:01:57.374-07:002018-06-09T21:01:57.374-07:00I agree that this is a clever interim fix, but I&#...I agree that this is a clever interim fix, but I'm not sold on it being a solid long-term idea.<br /><br />According to Bugzilla, they already want to implement official TCP/UDP Socket APIs, and recent clues suggest that they want to do it soon: https://bugzilla.mozilla.org/show_bug.cgi?id=1467145#c3<br /><br />Given that, I can't see why they wouldn't be willing to accept patches to help get it done sooner. That seems like a much less risky long-term prospect than having to maintain your own security-sensitive code on your own... though in fairness, maybe you'd still have to do that anyway; I don't know how much code specific to older OSX versions would be needed.<br /><br />What I do know is that this isn't really a question of willingness on Mozilla's part. There are lots of approved APIs waiting for design and implementation work, but not enough people to do actually do that work quickly enough for everyone's tastes. Mere willingness isn't enough. Relatively few people who sound willing are actually taking that extra step and helping to get things done.<br /><br />Maybe that's just because those folks don't have the time, or because they aren't really able to sling the lower-level code required, but either way the number of people working on the code isn't increasing. Simply adding more pressure isn't going to cut it.BashZeStampeedohttps://www.blogger.com/profile/08974610047844166539noreply@blogger.com