My comments on this:
- Maintaining code running in more environments is difficult.
- There is duplicated code (e.g. the XUL interface, Lib functions and various parts of Firebug infrastructure).
- HTTPM is embedded in Firebug as GIT Submodule. Feedback collected so far is rather against using submodules. Not sure if manual syncing is even an option.
The best would be if parts of different GIT modules could be shared. Maintaining lib functions in several repositories doesn't make sense in the long-term view.
- Firebug is going to loose Net panel translations. It's probably necessary to get them for HTTPM again (or convert existing firebug.properties file).
Translations should be extracted from existing
firebug.properties files. It will be more work for translators to do all their work again.
Long-term goal would be to get away from BabelZilla, but this requires another platform.
- Code in HTTPM must be often more generic since it's implementation can be different (break on next, initialization, etc.)
Is that code reusable now or does it require two different implementations?
- The future is uncertain (not sure whether the UI will be actually shared and how much it'll change when really integrated with Firefox).
Shared between Firebug and the web dev tools I guess? Probably not completely because these tools have their own layout.
- Firebug team is now maintaining yet another project (HTTPM).
If it can be achieved to just have to maintain one code base, this isn't a huge problem.
- Implementation of the remoting support requires improved Firebug infrastructure (e.g. new connection object). Similarly to the existing one, new API will be probably copied into HTTPM.
The question is still if the BTI should be reused for this or if we end up creating a new interface.
- NetExport needs to be refactored (and partially included in HTTPM?)
Does this mean NetExport should be integrated into HTTPM (and therefore into Firebug)?
--Sebastianz 06:15, 1 June 2012 (PDT)