Obviously, there's no reason we couldn't implement the WebKit/chrome protocol - it works for them, so it must also work as well for us.
However, our protocol has some nice characteristics. It's easy to extend and specialize for other kinds of tools and instrumentation, like the profiler, or to provide access to B2G content processes. And we have some improvements in the pipeline, like bulk data transfer, that should make it better for use on low-memory devices like phones. My sense here is that the interoperation story will never be good enough that it will actually be enough of an advantage to pay for the loss of the qualities I describe above. On Mon, Jan 14, 2013 at 6:12 AM, Jeremie Patonnier <[email protected]> wrote: > Hi, > > 2013/1/14 Panos Astithas <[email protected]> > >> This is getting off-topic, so if you want to talk about this further, >> let's continue the discussion in the dev-developer-tools mailing list. >> > > Agreed, feel free to remove the B2G/Gaia ML if it's to noisy :) > > >> In a nutshell, we originally considered using WebKit's protocol, but it >> proved too limiting in some ways. Jim can provide the details here. There >> is no such effort to standardize remote debugging protocols that we're >> aware of, but it sounds like something that *could* happen in the future. >> > > Ok, I had some discussion with Vincent Hardy (he's the guy that manage the > team that build all the Edge tools and the Cordova project at Adobe) and he > seams ok to go that way. Maybe it could be interesting to contact him to > start that standardisation effort. I have no idea on how to help starting > that effort except by providing useful contact, but let me know if I can > help in any way. > > >> Keep in mind though that until that time, implementation differences >> across browsers will be better debugged with the native tools in each one, >> since other vendors won't have the incentive to develop (and test!) >> features that aren't pertinent to their product. >> > > Obviously, but this is painful to web dev and in that case, they will > choose the easiest tools to use. At that time, it means Chrome Tools or > Adobe Tools (that are WebKit only in such a matter). So my very personal > opinion is that Mozilla have interest in having such > standard agnostique tools. The longer a standardisation effort will take to > start, the longer the web dev will suffer (and choose the easiest way... > the path to the dark side according to master Yoda... sorry) > > It remind me that old bug I fill a year ago: > https://bugzilla.mozilla.org/show_bug.cgi?id=734055 > Beyond the technical part (where I'm not good at) let me know if I can help > to such a standardisation effort. > > Best, > -- > Jeremie > ............................. > Web : http://jeremie.patonnier.net > Twitter : @JeremiePat <http://twitter.com/JeremiePat> > > > >> >> Panos >> >> >> >> On Sun, Jan 13, 2013 at 8:07 PM, Jeremie Patonnier < >> [email protected]> wrote: >> >>> Just a few thought about that topic. >>> >>> I regularly talk with people from Adobe and Opera and I'm still surprise >>> that their is not a concerting effort to produce a standard debugging >>> protocol for JavaScript and browsers (or things like FIrefoxOS or >>> ChromeOS). My concern as a Web Developer is that I will have to use several >>> different incompatible tools to remote debug a single Web App in several >>> environment. This fragmentation is a risk for a niche product such as >>> Firefox OS which need a strong basis of developers to build apps that make >>> the product appealing. >>> >>> Is their some people working on such a debug protocole at Mozilla? Does >>> Mozilla has plan to work with other browser vendors on that topic (At W3C >>> or else where)? >>> >>> Thanks >>> ++ >>> Jérémie >>> >>> >>> 2013/1/12 Panos Astithas <[email protected]> >>> >>>> On Sat, Jan 12, 2013 at 4:31 AM, Fabrice Desre <[email protected]> >>>> wrote: >>>> > >>>> > On 01/11/2013 06:09 PM, David Bruant wrote: >>>> > >>>> > > I've discovered on the devengage mailing list [1] that as of January >>>> > > 10th, remote debugging for FirefoxOS has been disabled. This is quite >>>> > > unfortunate, because remote debugging makes a tremendous difference >>>> in >>>> > > my work studying and documenting the APIs. It's also obviously a much >>>> > > needed feature for app developers. >>>> > > A couple of questions remain unanswered: >>>> > > * Why has this been decided? >>>> > >>>> > The remote debugging support we have currently on b2g only allow >>>> > debugging the chrome process. This was a huge security issue since this >>>> > process runs as root on device. Unfortunately the work needed to debug >>>> > content processes is not finished yet (there are bugs filed, but I >>>> don't >>>> > know the numbers). >>>> >>>> Bug 797627 tracks this work and Jim is working on it. I'll probably also >>>> pitch in to help with debugger frontend changes, after the protocol bits >>>> are in place. >>>> >>>> > > * Is it planned to re-enable it in its previous form? a new form? >>>> > >>>> > As soon as the devtools team get content processes debugging working, >>>> > we'll happily enable that support. Note that we didn't disable support >>>> > on b2g desktop, where out of process is disabled, so devs can debug >>>> there. >>>> > >>>> > > * Has a date or milestone been decided to fix this issue? >>>> > >>>> > I don't know. Panagiotis may tell us more! >>>> >>>> Since we re-enabled debugging support for desktop b2g builds yesterday >>>> (bug >>>> 784824, bug 829633 - still needs a+ for b2g18), I believe the urgency of >>>> the matter has subsided somewhat. We can at least proceed with the >>>> Firefox >>>> OS App Days schedule as planned, which was my immediate concern. >>>> >>>> I'm also trying to figure out ways to enable debugging for non-production >>>> builds, but Fabrice tells me it's not that easy to do this in gecko land. >>>> Any help here is more than welcome! >>>> >>>> Supporting subprocesses is non-trivial work, as it needs significant >>>> modifications to the protocol specification, as well as the >>>> implementation >>>> of client (frontend) and server. I can't speak for Jim on that, but at >>>> the >>>> same time I'm trying a few ideas right now to see if we can have a >>>> secure, >>>> albeit limited, debugging functionality for production devices. I'll >>>> probably add any new patches in bug 817580, since I intend to tweak what >>>> we >>>> have there a bit. >>>> >>>> > > * If it takes too long to fix, what are the other ways to debug apps >>>> on >>>> > > an actual device? >>>> > >>>> > None that I know of. >>>> >>>> Neither do I. >>>> >>>> > > Besides these questions to understand the current situation, I'd >>>> like to >>>> > > discuss a trend I'm noticing. I am under the impression that app >>>> > > developers are becoming a growing population of the FirefoxOS >>>> ecosystem >>>> > > especially with Mozilla increasingly reaching out to potential such >>>> > > developers (app days all over the globe in the upcoming weeks). I >>>> feel >>>> > > it will become increasingly important for this population to have a >>>> > > stable development environment and if for good reasons the >>>> environment >>>> > > can't be kept stable, alert this population of the upcoming change >>>> that >>>> > > may affect it. >>>> > >>>> > I agree. But we have tight schedules so we can't usually give notice >>>> too >>>> > much in advance. For this particular topic, we discussed the problem >>>> and >>>> > solutions on Monday, and got code landed Wednesday. Being in a frantic >>>> > work week, we didn't make a great job reaching out to developers. We'll >>>> > do our best to better communicate such changes in the future. >>>> >>>> >>>> I'll just add that the thought of me presenting on our local App Day only >>>> to say "sorry but there is no way to debug your apps" was pretty >>>> terrifying, so rest assured we all share your concerns. >>>> >>>> Panos >>>> _______________________________________________ >>>> engagement-developers mailing list >>>> [email protected] >>>> https://lists.mozilla.org/listinfo/engagement-developers >>>> >>> >>> >>> >>> -- >>> Jeremie >>> ............................. >>> Web : http://jeremie.patonnier.net >>> Twitter : @JeremiePat <http://twitter.com/JeremiePat> >>> >> > _______________________________________________ > dev-developer-tools mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-developer-tools _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
