This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | embedded browser friend API review | ||
---|---|---|---|
Product: | platform | Reporter: | Stanislav Aubrecht <saubrecht> |
Component: | -- Other -- | Assignee: | apireviews <apireviews> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | anebuzelsky, dlipin, hmichel, mfukala, mkubec, saubrecht, tmysik |
Priority: | P2 | Keywords: | API, API_REVIEW |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://wiki.netbeans.org/EmbeddedBrowserPlan68 | ||
Issue Type: | TASK | Exception Reporter: | |
Attachments: | proposed friend API |
Description
Stanislav Aubrecht
2009-06-30 15:38:14 UTC
Created attachment 84193 [details]
proposed friend API
current implementation details: - the actual browser integration is based on MozSwing project (http://sourceforge.net/projects/mozswing) which uses Mozilla's XULRunner to create a Java wrapper for browser component - MozSwing bundles all necessary binaries for each supported platform (win32, unix/linux, mac os x, solaris), the total size of these files is about 46MB (approximately 10MB per platform) - there will be a new module core.browser in platform cluster which will bundle XULRunner binaries and MozSwing jars and hide all implementation details in its own Java API (see attachment) - there will be another implementation of URLDisplayer that will open links in an internal browser window in NetBeans and which will be visible in Tools/Options as an 'Internal Browser' the plan is to have the initial implementation of embedded browser in netbeans 6.8 milestone 1 > - there will be a new module core.browser in platform cluster
> which will bundle XULRunner binaries and MozSwing jars and
> hide all implementation details in its own Java API (see attachment)
For the first release of NetBeans with the embedded browser, I would like to have EB in ide cluster not in platform cluster.
I'd like the API to anticipate and get more ready for its future evolution. Here is the list of advices: Y01 WebBrowserListener is not evolvable. I'd probably suggest to add also WebBrowserEvent and in future extend that event with more and more information. Y02 WebPreviewable shall be split into two parts (API vs. SPI). final class WebPreviewable with factory method that takes an interface WebPreviewable.Impl - in future there would be more factory methods and more interface. The WebPreviewable could get more and more methods. Y03 I am not really happy that WebBrowser extends HtmlBrowser.Impl. This creates an unwanted connection between these two APIs imho. Either merge them in one (by enhancing API of HtmlBrowser and Impl) or separate them. The same applies to the factory. But probably this needs more discussion (is this really a fast track)? Y04 Adding 46MB is quite a lot. I'd expect each installer to carry just the part appropriate to its operating system. Default zip distro could possibly contain no implementation by itself. One shall be able to download a single module with browser for linux/win/macos/solaris from AU. (is this really a fast track)? That is probably all for now. As I mentioned twice, I believe it would be more effective to call standard review sometime next week than trying to keep the discussion in IZ. Review: Approved with TCRs and TCAs: Standa A., Jarda T., Tonda N., Dmitrij L., Marek F. Milan K. SA: Packaging: 4 separate modules for binaries. Installer would include just one of the modules. DL: Doable. Can the binaries be in separate modules? core.browser.solaris, core.browser.windows, etc. SA: Yes. MF: What will be in ZIP file? Vote: No binaries in ZIP file, download on first use. TN: Now it is in ide cluster, download ok, in future more to platform. DL: Where to put the binaries? On update center. How to modify the build scripts? DL: Preferably: Archive each binary into own ZIP file, pass it to installer. (TCR to change build system). TN: How much work is on the side of installers? DL: One day. SA: Y01. OK. Possibly leave just one method and WebBrowserEvent with cancel(), setURL(...), etc. SA: Y02. OK. SA: Y03. OK, if possible. Discussion about cookies. There is an API in 1.6, but we are still stuck with 1.5. JT: Simple API now, migrate to 1.6 API in future. TN: Let's discuss usecases. MK: getContent() shall be named getDocument() MF: Add note that the document is modifiable. SA: WebBrowser.getComponent is just the browser component no surroundings TN: Module system supports dependencies on JDK1.6, Linux, etc. JT: Moreover you can extend the set of dependencies SA: There will be logic in core.browser module to decide JT: Advice to have a property to decide whether the browser shall be on or off implemented in core-main beeb098a02c0 Integrated into 'main-golden', will be available in build *200907150249* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/beeb098a02c0 User: S. Aubrecht <saubrecht@netbeans.org> Log: #167901 - initial version of embedded browser Integrated into 'main-golden', will be available in build *200907160201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/fd60eae0cbe0 User: S. Aubrecht <saubrecht@netbeans.org> Log: #167901 - document new dispose() method in api changes |