Closed Bug 99621 Opened 23 years ago Closed 14 years ago

Freeze nsIFontPackageService and nsIFontPackageHandler

Categories

(Core Graveyard :: Embedding: APIs, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX
Future

People

(Reporter: chak, Unassigned)

References

Details

Attachments

(1 file)

Freeze nsIFontPackageService and nsIFontPackageHandler

Please refer to
http://www.mozilla.org/projects/embedding/EmbedInterfaceFreeze.html for the
issues to be addressed, if any, for this interface.

Please follow the guidelines outlined in "How to mark an interface as frozen?"
section of the document above.
Blocks: 98417
QA Contact: mdunn → depstein
When should this be done? What is the time table. 
Status: NEW → ASSIGNED
Ahhhhh, sorry frank.   I meant to do this while you are away.
Here is what I get from Chak few days back:

=============================================================
It's not late at all to add your interfaces to the freeze list.

Here's the process we're following:

1. Take a look at
http://www.mozilla.org/projects/embedding/EmbedInterfaceFreeze.html and make a
list of interfaces you own that are ready to be frozen.  If you see intertfaces
which you'd like to see frozen but are not there please let me know i'll update
the doc.

2. File a bug saying that an interface(s) need to be frozen as per the
"interface freeze guidelines" as described in the doc above

3. Please add the bug filed in step 2 above as a dependency to the meta bug at
http://bugzilla.mozilla.org/show_bug.cgi?id=98417

Hi Frank/Roy:

The process outlined above (steps 1 - 3 are already done):

For freezing of nsIFontPackageService and nsIFontPackageHandler are already
covered by this bug. I've also updated the meta bug #98417.
As far as the timeframe is concerned if these interfaces are ready to be frozen
then we'd like to get them frozen asap.

Thank You
->0.9.6

Hi Frank/Roy : 

Can we get these into 0.9.6....

Thanks 
Chak
Target Milestone: --- → mozilla0.9.6
Attached patch diffSplinter Review
Comment on attachment 54104 [details] [diff] [review]
diff

r=chak
Attachment #54104 - Flags: review+
ask for sr=
Blocks: 104148
Why does this interface need to be frozen and supported in its current form? 
How do embedders need to use it in order to do the things we want to support? 
Why is this interface, in this form, the correct thing?

I'd like to see these questions answered, in this bug, before we freeze anything.
>Why does this interface need to be frozen and supported in its current form?
Why not? not sure how to answer this qustion.
 
>How do embedders need to use it in order to do the things we want to support? 
Embedder may use this interface to 
1. supply a dummy font package handler which do NOT download any font, or
2. supply a font package handler which download a font from a different places

the reason we need to let embedder to do so is because different embedder may 
have different legal contact with font. Sometime they may want to supply a font 
package handler which connect to their website and download font .

>Why is this interface, in this form, the correct thing?
Why not?
I agree with ftang - not sure why these can't be frozen.

Other embedding clients are already using these interfaces to download and
install their own font packages.
Everytime we freeze an interface, we're saying that be value permanent support
for that interface, and its current semantics, over the opportunities for
improvement (performance, extensibility, compatibility, whatever) we're losing
by giving up the  ability to change it.  Being conservative about what
interfaces we freeze, and exposing only minimal, necessary functionality to
embedders, makes our future work easier, which is why I ask "why does this need
to be frozen?".  We don't want to freeze all of our interfaces just because
they're there.

We have an API review process, and it's working well for us.  It helps us answer
these questions, and decide which interfaces we need to be supporting for the
life of Mozilla 1.x.  Have you submitted this interface for that review process?
 I haven't seen it on any of the agendas, to my knowledge.
note the font handling section in the API review notes
(http://www.mozilla.org/projects/embedding/apiReviewNotes.html#Font_Downloading ).

I haven't synched the current state of these iface w/ the notes (that needs to
happen).

Re: a minimal set of ifaces for freezing. as shaver states, we want this set to
nver be greater than what we can support going forward. Because this concept is
new to us, we want to make sure this set is as small as possible (as shaver
points out, it's less work for us).

Fond handling on freezing radar because embeddors need the ability to download
fonts that aren't generally distributed.
shaver, what we need from here to get a sr=? We are not quite sure about your 
question.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
move to 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
mass move unimportant m9.8 bug to m9.9 for now. 
Target Milestone: mozilla0.9.8 → mozilla0.9.9
I see this going nowhere now. Move to future. 
Target Milestone: mozilla0.9.9 → Future
can you ellaborate on "nowhere"? Embedding customers are still using this.
nominating 0.9.9
Keywords: mozilla0.9.9
No longer blocks: 104148
QA Contact: depstein → dsirnapalli
Blocks: 157137
what a hack. I have not touch mozilla code for 2 years. I didn't read these bugs
for 2 years. And they are still there. Just close them as won't fix to clean up.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
Mass Bug Re-Open of bugs Frank Tang Closed with no good reason. Spam is his
fault not my own
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Mass Re-assinging Frank Tangs old bugs that he closed won't fix and had to be
re-open. Spam is his fault not my own
Assignee: ftang → nobody
Status: REOPENED → NEW
Filter on "Nobody_NScomTLD_20080620"
QA Contact: dsirnapalli → apis
We don't freeze interfaces anymore.
Status: NEW → RESOLVED
Closed: 19 years ago14 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.