dave
([EMAIL PROTECTED])
David Hyatt wrote:
[EMAIL PROTECTED]"> 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
