As we move forward, i believe that it is important to build all of our "clients" on top of well-defined public APIs. The discussion that jud is initiating is a first step toward identifying areas in the current codebase that can be transitioned to use public APIs (as they become available). The other benefit to this exercise is to identify areas where current client functionality *cannot* be achieved via public APIs.
-- rick
David Hyatt wrote:
We need first to identify which embedding APIs are relevant for XUL. Although some simplify things for XUL, other APIs are complicated and unnecessary when you live directly within the DOM. Many of the embedding APIs are unnecessary in the XUL world, and they should not be used by the XUL client.I just want to clarify that up front to head off efforts to use the embedding APIs in XUL in places where it does not make sense to do so. A XUL application will never use all of the embedding APIs. It will only use a subset.
dave
([EMAIL PROTECTED])Judson Valeski wrote:
[EMAIL PROTECTED]">If the mozilla standalone client is ever going to become a true "embedding API" customer, we need to sort out the cross-over between the embedding implementation, and the "main" implementation of various sub-systems.There are a few pieces I can enumerate off of the top of my head (with varying degrees of depth. please add/modify as necessary) that we have duplicate (different) implementations in the embedding and mozilla app cases:
sub-system Mozilla Embedding "windows" nsXULWindow nsGlobalWindow save-as proprietary nsWebBrowserPersist printing proprietary nsIWebBrowserPrint command handling proprietary nsICommandHandler To what degree the two worlds collide is up for debate, but at a minimum, we need to remove the redundancy because it leads to duplicate debugging efforts and fixes, as well as inconsistent semantics which dilute our embedding story.
Jud
