Re: Integrating the developer tools debugger

Hey, that is great news.

I have had som success using Venkman in Thunderbird lately, but it is 
buggy there.

I'll opt for solution C2.

I like to see the possibility to update out of the normal TB-Update 
cycle, so that kills option B
Since TB does not package extensions, option A seems to cause much more 
integration work than the others.
Option C1, lacks the visibility I believe is a good thing.

With C2, you can have the extension always up to date in your builds 
without having to think about it after configuring it once.
If you then happen to need the debugger - it's there.

Best Regards
Markus


Am 08.07.2013 15:11, schrieb Philipp Kewisch:
> Hey Folks,
>
> as you may know, I am working on integrating the Developer Tools 
> Debugger into Thunderbird, so we can once again use a real debugger 
> for development. The debugger server is packaged by Mozilla's Toolkit, 
> so as long as its packaged, it will be possible to make use of it. The 
> only thing missing is UI and a few actors to make sure a Firefox 
> client can connect. More details on the initial implementation is 
> here: 
> http://kewisch.wordpress.com/2013/06/13/the-thunderbird-remote-debugger-is-alive/
>
> One important thing to decide on is how to actually package the 
> debugger. While the initial patches went into comm-central before the 
> last merge, there are more (possibly better) options to consider to 
> make sure that the debugger is available for all products. I'd love to 
> hear some feedback from at least one person from each product.
>
> *Option A: package extension as an extension within the app*
>  - Here we would have a single directory in the build system that 
> packages the debugger server glue as an extension
>  - The extension would be installed and distributed with Thunderbird, 
> similar to how Seamonkey packages Chatzilla et al.
>  - The extension can be extracted from Thunderbird for uploading to AMO.
>  -Downside: Thunderbird usually doesn't package extensions, TestPilot 
> is going away too
> - Upside: High visibility for developers, easier for others to 
> contribute to the debugger if they are contributing to comm-central too.
> *
> **Option B: package files directly in app, extra extension directory *
> - The extension files get installed into dist/bin, not in the 
> extensions dir
> - This way the extension is installed natively, without an 
> addon-manager entry
> - An extra directory exists in the build system to generate the same 
> code as an extension, for uploading to AMO
> - Upside: No extra entry in the addons manager
> - Downside: No way to update the debugger glue without a full product 
> update
>
> *Option C1: package as an extension only*
>  - The code would be removed from comm-central altogether, instead 
> added to a repository on my github account
>  - AMO uploads can be made periodically by zipping the source code as 
> an xpi
>  - Upside: No extra work for packaging, no maintenence in comm-* 
> repositories
>  - Upside: Not installed for anyone that doesn't use the debugger
>  - Downside: Localization needs to be managed externally
>  - Downside: Visibility is not very high. Would need to do some PR to 
> make sure its known to developers
>  - Downside: Yet another external repository for apps wanting to 
> include the extension by default
> *
> **Option C2: package as an extension, download in client.py*
>  - Like option C1, but instead host on github/mozilla-comm
>  - Make client.py automatically check out the extension into 
> mozilla/extensions
>  - Add build system magic to allow building with the mozilla build system
>  - Upside: More visibility than C1
>  - Downside: Adds build system maintenance, also another external 
> repository
>
>
> Just an extra note, the overhead for the js debugger glue is very 
> small, especially with the default of the debugger being off. I'm not 
> going to say my preference now to get a most unbiased opinion, but I 
> may chime in later on.
>
> Looking forward to your feedback!
> Philipp
>
>