Brian Stell wrote:Jud,all of the above :-). In general our strategy is to minimize what we make public (ie. minimize the set and methods on interfaces we're going to call "embedding" interfaces). We want this list to be minimal because whatever the list is, we're signing up to support it, document it, own it, and provide backwards compatibility strategies for it. If I send you a list of 100 ifaces and say you can use them, that's a lot maintenance for me to do to keep you happy. The other primary reason we want to minimize this list is because mozilla is 1.0 software and we know we're going to be changing semantics/interfaces, so it's easier to expose some simplistic interface we know we can support anyway we have to underneath the covers, thus removing a binding on us to maintain our existing implemnetations.In general, are we:
creating new interfaces
advantage: minimal interface
disadvantage: more interfaces
orare we re-using existing interfaces?
disadvantage: interfaces cluttered with stuff we don't want embedders to see/use
advantage: less interfacesThe above principles have forced us to take existing interfaces and cut stuff we're unsure will stand the test of time out into an internal interface that we don't publicize. They've made us create completely new interfaces that expose things for the first time. And they've made us re-think some of our current semantics and subsequently change them.
We already have an i18n interface that is close:If adding to it is going to render some methods useless in the embedding context (the parent method seems questionable) then start fresh. If you can add to it, and embeddors are going to need the existing methods anyway, *and* you can leverage the methods internally as well; great!http://lxr.mozilla.org/seamonkey/source/intl/chardet/public/nsIDocumentCharsetInfo.idl
Should I just add to it or start new?
http://www.mozilla.org/projects/embedding/apiReviewNotes.html points out some nit-picky meetings where we've pushed single methods down into internal interfaces and cut interfaces completely in half in the name of clarity and cleanliness.
Our job is to make the embeddor's lives simple and understandable. If we have to say "use this interface but ignore this method because it can't mean anything in your context," we've failed.
Does that help?
Jud
Brian
Judson Valeski wrote:
One of the requirements of embedding is that all functionality is provided through nsI interfaces. those interfaces comprise the "embedding" package and explain how you do certain things. The links below are to class implementation files which will not be public. I suspect we'll need to create a new, public, i18n interface that exposes that functionality somehow.Does that make more sense?
Jud
Brian Stell wrote:
Judson Valeski wrote:
What interface do these methods hang off of?(I'm not sure I understand exactly what I'm doing here)SetForcedCharacterSet() is part of class nsDocumentCharsetInfo
http://lxr.mozilla.org/seamonkey/source/intl/chardet/src/nsDocumentCharsetInfo.cpp#43SetDefaultCharacterSet is part of class DocumentViewerImpl
http://lxr.mozilla.org/seamonkey/source/layout/base/src/nsDocumentViewer.cpp#1883GetDocumentCharacterSet is part of class nsDocument
http://lxr.mozilla.org/seamonkey/source/layout/base/src/nsDocument.cpp#1069
Brian Stell wrote:> Jud,
>
> Here is a first rough cut at the i18n embedding APIs:
>
> 1) set default charset
>
> SetDefaultCharacterSet(const PRUnichar* aForceCharacterSet)
>
> 2) force charset override
>
> SetForcedCharacterSet(const PRUnichar* aForceCharacterSet)
>
> Note: this needs to be followed by a reload
>
Hmm. I suspect we'll want to force the reload ourselves. That would give
us control over *how* the doc got reloaded. We obviously don't want to
hit the server again for a charset change.Jud
> 3) find out what charset was used and how selected
>
> GetDocumentCharacterSet(nsAWritableString& oCharSetID)
>
> Can you help me put this into a suitable form?
>
> Thanks
>
> Brian
>
>
>
