removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

19 views
Skip to first unread message

jos...@gmail.com

unread,
Mar 20, 2009, 8:17:41 PM3/20/09
to sha...@mozilla.com, dsi...@mozilla.com, bre...@mozilla.com, j...@mozilla.com
We're currently planning to remove OJI, LiveConnect, and the XPCOM
plugin API from Gecko 1.9.2. We've worked hard to get to a point where
this would be possible and I believe we can make these changes in
Gecko 1.9.2.

We are planning to remove those components because they are largely
unmaintained, they have few consumers, and there are better
alternatives.

To put this change in perspective in terms of a timeline, the earliest
a browser with those changes would ship would be approximately Q2
2010.

There are three major consumers of these components - Sun's Java
plugin, Steven Michaud's JEP, and the Real player. Sun has worked with
us to develop a new Java plugin based on NPAPI and NPRuntime, removing
their dependency on OJI/LiveConnect and the XPCOM plugin API. This new
plugin is already available for Windows and Linux and will be coming
to Mac OS X soon. When the new plugin arrives for Mac OS X it will be
an alternative to the JEP. As for Real player, we are working with
Real to move them to NPAPI and NPRuntime as well.

Our plan for Java on Mac OS X is to ship the JEP in Firefox 3.5, which
should be supported until around Q4 2010. The Gecko 1.9.2 branch will
not support JEP. It will use the new Java plugin from Sun and Apple,
which will be available before a browser based on Gecko 1.9.2 becomes
available.

The question at hand now is when to actually commit the changes to the
1.9.2 branch. The removal is not simple and the improvements we plan
to make once those components are out of the way will take time
(including major simplification and cleanup in our plugins module).
This is not a change we can make at the last minute. I'm inclined to
commit the removal in April but I'd appreciate feedback on timing.

The argument against committing now is that we'll go for a period of
time on the trunk without a Java plugin on Mac OS X and without Real
player on all platforms. However, we are not losing regression
coverage because both plugins are being replaced entirely and users
that actually need those capabilities can use Firefox 3.5. I can't
comment further on the timelines for re-gaining support in Gecko 1.9.2
but they are well within the Gecko 1.9.2 development time frame.

The argument for committing now is that this is a major change, we
need time and we're not losing coverage of plugins that we'll be
supporting when we ship. It also gives plugin developers more time to
develop against the exact set of plugin APIs that will be available to
them when we ship.

Fun fact: a basic removal patch for this stuff is ~6MB and growing.

-Josh Aas

Kevin Brosnan

unread,
Mar 21, 2009, 1:27:15 AM3/21/09
to jos...@gmail.com, dev-pl...@lists.mozilla.org
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>

Is there any (easy) way to test the plugins at
http://plugindoc.mozdev.org/windows-all.html for use of code that
would be effected by this change? Or would a direct email to the
developers, if they can be located make sense? I know that these
plugins represent a fractional percentage of plugin usage. However
making a good faith effort that alerts them to the change as early as
possible makes sense as they may not closely follow NPAPI development.

Igor Bukanov

unread,
Mar 21, 2009, 7:07:00 AM3/21/09
to jos...@gmail.com, dev-pl...@lists.mozilla.org, dsi...@mozilla.com, bre...@mozilla.com, sha...@mozilla.com, j...@mozilla.com
2009/3/21 <jos...@gmail.com>:

> This is not a change we can make at the last minute. I'm inclined to
> commit the removal in April but I'd appreciate feedback on timing.

The liveconnect, which uses C, currently includes non-public
SpiderMonkey headers. Since SpiderMonkey uses C++ this requires
workarounds in the headers to hide C++ constructions incompatible with
C to make sure that liveconnect compiles.

With liveconnect removed those headers would inevitably quickly became
C++ only on 1.9.2 branch. That would mean that backports to 1.9.1 may
require extra efforts. Given the amount of 1.9.1 blockers it would be
nice to avoid any potential additional work until, say, RC1. So at
least with liveconnect I suggests to wait with its removal until
Firefox 3.5 RC1.

Igor

gNeandr

unread,
Mar 21, 2009, 11:51:05 AM3/21/09
to
There have been postings to other groups (eg. m.d.ext) to ask about the
current/future support of JAVA.

I have discussed with a pure JAVA base app
(http://www.finchsync.com/index.html [FS]) for sync TB/AB and ICS data
(Lightning, Reminderfox etc) to change that application having a Mozilla
based support, at least to use the new methods to access TB/AB directly.
That would require to adapt Mozilla code with main parts of JAVA based
FS or to build an extension and "encapsulated" parts of FS (eg. using
their sync based on on .NET etc).

QQ: With the mentioned change for Gecko 1.9.2 can anybody recommand
which is the 'best' way to get that done? Any suggestions?

Günter

jos...@gmail.com

unread,
Mar 21, 2009, 1:28:57 PM3/21/09
to
On Mar 20, 10:27 pm, Kevin Brosnan <kbros...@gmail.com> wrote:
> Is there any (easy) way to test the plugins athttp://plugindoc.mozdev.org/windows-all.htmlfor use of code that

> would be effected by this change? Or would a direct email to the
> developers, if they can be located make sense? I know that these
> plugins represent a fractional percentage of plugin usage. However
> making a good faith effort that alerts them to the change as early as
> possible makes sense as they may not closely follow NPAPI development.

Good idea, I'll look into notifying them of this change.

jos...@gmail.com

unread,
Mar 21, 2009, 1:30:20 PM3/21/09
to
On Mar 21, 4:07 am, Igor Bukanov <i...@mir2.org> wrote:
> 2009/3/21  <josh...@gmail.com>:

That is fine with me, I'll make sure we wait until at least 3.5 RC1 to
remove LiveConnect.

Robert Kaiser

unread,
Mar 22, 2009, 9:55:04 AM3/22/09
to
jos...@gmail.com wrote:
> The question at hand now is when to actually commit the changes to the
> 1.9.2 branch.

Should be before the first Alpha IMHO, so that anyone doing/starting
stuff based on any "official" prerelease wouldn't rely on those
functionalities.

Robert Kaiser

Peter Weilbacher

unread,
Mar 22, 2009, 6:48:06 PM3/22/09
to
On 21.03.09 01:17, jos...@gmail.com wrote:
> There are three major consumers of these components - Sun's Java
> plugin, Steven Michaud's JEP, and the Real player. Sun has worked with
> us to develop a new Java plugin based on NPAPI and NPRuntime, removing
> their dependency on OJI/LiveConnect and the XPCOM plugin API. This new
> plugin is already available for Windows and Linux

Can you be a bit more specific? Which version(s) of the Sun plugin are
NPAPI-based?
Peter.

Boris Zbarsky

unread,
Mar 22, 2009, 8:18:33 PM3/22/09
to
jos...@gmail.com wrote:
> To put this change in perspective in terms of a timeline, the earliest
> a browser with those changes would ship would be approximately Q2
> 2010.

Is that seriously how late the release after 1.9.1 is planned for?
That's rather sad-making. I was hoping we'd do a Gecko release before
that. :( Was there a discussion I missed somewhere?

> The argument against committing now is that we'll go for a period of
> time on the trunk without a Java plugin on Mac OS X and without Real
> player on all platforms. However, we are not losing regression
> coverage because both plugins are being replaced entirely and users
> that actually need those capabilities can use Firefox 3.5.

We might be using trunk testing coverage in general, though, if people
can't use it because sites they rely on don't work without Java.... Do
we have any data on this?

-Boris

jos...@gmail.com

unread,
Mar 22, 2009, 9:31:00 PM3/22/09
to
On Mar 22, 5:18 pm, Boris Zbarsky <bzbar...@mit.edu> wrote:

> josh...@gmail.com wrote:
> > To put this change in perspective in terms of a timeline, the earliest
> > a browser with those changes would ship would be approximately Q2
> > 2010.
>
> Is that seriously how late the release after 1.9.1 is planned for?
> That's rather sad-making.  I was hoping we'd do a Gecko release before
> that.  :(  Was there a discussion I missed somewhere?

This is an estimate of mine, I haven't heard any formal plans. Planned
is < actual in almost every case anyway, and Q2 2010 is less than 1
year after 1.9.1. I'd be extremely surprised if we saw a 1.9.2 release
before March of 2010.

> > The argument against committing now is that we'll go for a period of
> > time on the trunk without a Java plugin on Mac OS X and without Real
> > player on all platforms. However, we are not losing regression
> > coverage because both plugins are being replaced entirely and users
> > that actually need those capabilities can use Firefox 3.5.
>
> We might be using trunk testing coverage in general, though, if people
> can't use it because sites they rely on don't work without Java....  Do
> we have any data on this?

I think the number of Mac OS X trunk nightly users that rely on Java
so much that they can't occasionally use Firefox 3.5 for a bit is very
small. I'm not worried about their impact on overall nightly testing
coverage. I have no idea where we'd get data on that.

Boris Zbarsky

unread,
Mar 22, 2009, 10:02:01 PM3/22/09
to
jos...@gmail.com wrote:
> I think the number of Mac OS X trunk nightly users that rely on Java
> so much that they can't occasionally use Firefox 3.5 for a bit is very
> small. I'm not worried about their impact on overall nightly testing
> coverage. I have no idea where we'd get data on that.

We can start by getting data on how many trunk OSX users we have to
start with.... Then we could consider widely asking this question and
see what responses we get from them.

-Boris

Boris Zbarsky

unread,
Mar 22, 2009, 10:05:10 PM3/22/09
to
jos...@gmail.com wrote:
> I think the number of Mac OS X trunk nightly users that rely on Java
> so much that they can't occasionally use Firefox 3.5 for a bit is very
> small. I'm not worried about their impact on overall nightly testing
> coverage. I have no idea where we'd get data on that.

And it's not just "occasionally use Firefox 3.5 for a bit". It's a
matter of having to maintain a separate profile for that use (because
going back and forth across versions on a given profile is NOT something
one ever wants to do), remembering to always start Firefox 3.5 when
going to some particular sites, remembering to not use it for going to
other sites, having bookmarks and history forked, etc.

Basically, if there were even one site that needs me to use Java, I'd
not bother running trunk builds at all in the above setup. It'd just be
too much pain.

I think none of the sites I care about in fact use Java, but I'm not a
good representative sample (e.g. 60+% of my web browsing is Bugzilla).

-Boris

Justin Dolske

unread,
Mar 22, 2009, 11:17:43 PM3/22/09
to
On 3/22/09 7:05 PM, Boris Zbarsky wrote:
> jos...@gmail.com wrote:
>> I think the number of Mac OS X trunk nightly users that rely on Java
>> so much that they can't occasionally use Firefox 3.5 for a bit is very
>> small. I'm not worried about their impact on overall nightly testing
>> coverage. I have no idea where we'd get data on that.

Crazy idea -- turn it off now, maybe just for a week or two, and see if
anyone screams bloody murder?

> Basically, if there were even one site that needs me to use Java, I'd
> not bother running trunk builds at all in the above setup. It'd just be
> too much pain.

Yeah. I'd guess that user are largely divided into 2 buckets... Those
that simply never encounter Java online, and those who use it frequently
(likely because their employer/school has some tool that requires it).
How big and how important that latter bucket is, I don't know.

FWIW, I disabled Java in my daily-use profile a long time ago. About the
only things I've run across (rarely) that need it are a few online
games, and demos on educational pages.

Justin

Igor Bukanov

unread,
Mar 22, 2009, 11:27:04 PM3/22/09
to Justin Dolske, dev-pl...@lists.mozilla.org
2009/3/23 Justin Dolske <dol...@mozilla.com>:

> About the
> only things I've run across (rarely) that need it are a few online games,
> and demos on educational pages.

Some banks use Java for netbanking and there are photo-sharing or
printing sites that use signed Java applet to implement multiple image
upload.

Igor

jos...@gmail.com

unread,
Mar 23, 2009, 1:52:46 AM3/23/09
to
On Mar 22, 3:48 pm, Peter Weilbacher <newss...@weilbacher.org> wrote:

The new NPAPI/NPRuntime-based Java plugin is available for Windows and
Linux starting with Java SE 6 Update 10.

timeless

unread,
Mar 23, 2009, 2:50:03 AM3/23/09
to mozilla.dev.planning group
On Mon, Mar 23, 2009 at 5:27 AM, Igor Bukanov <ig...@mir2.org> wrote:
> Some banks use Java for netbanking and there are photo-sharing or
> printing sites that use signed Java applet to implement multiple image
> upload.

My bank is one of those stupid banks. (It's a subsidiary of Danske
bank and the java requirement was introduced after Dasnke bought my
bank, so I'd imagine it's a feature of their somewhat widely spread
Nordic banking services).

It turns out for very basic operations if you're incredibly clever you
can find a mobile page that works, but it requires either speaking
some obscure language or speaking that obscure language and hacking
urls.

OTOH, as w/ bz, I'm not the target audience, since I can't run a
modern gecko on my mac anyway.

Robert Kaiser

unread,
Mar 23, 2009, 8:50:24 AM3/23/09
to
jos...@gmail.com wrote:
> On Mar 22, 5:18 pm, Boris Zbarsky<bzbar...@mit.edu> wrote:
>> josh...@gmail.com wrote:
>>> To put this change in perspective in terms of a timeline, the earliest
>>> a browser with those changes would ship would be approximately Q2
>>> 2010.
>>
>> Is that seriously how late the release after 1.9.1 is planned for?
>> That's rather sad-making. I was hoping we'd do a Gecko release before
>> that. :( Was there a discussion I missed somewhere?
>
> This is an estimate of mine, I haven't heard any formal plans. Planned
> is< actual in almost every case anyway, and Q2 2010 is less than 1
> year after 1.9.1. I'd be extremely surprised if we saw a 1.9.2 release
> before March of 2010.

Note that the actual intention of the post-1.9.0 smaller-release plan
was to release more often, i.e. about every 6 months. Unfortunately we
largely failed to do that with 1.9.1 but maybe we manage to really
improve this and and come nearer towards the actual plan next time around.

Robert Kaiser

Peter Weilbacher

unread,
Mar 23, 2009, 11:19:10 AM3/23/09
to
On 03/23/09 13:50, Robert Kaiser wrote:

> jos...@gmail.com wrote:
>> This is an estimate of mine, I haven't heard any formal plans. Planned
>> is< actual in almost every case anyway, and Q2 2010 is less than 1
>> year after 1.9.1. I'd be extremely surprised if we saw a 1.9.2 release
>> before March of 2010.
>
> Note that the actual intention of the post-1.9.0 smaller-release plan
> was to release more often, i.e. about every 6 months. Unfortunately we
> largely failed to do that with 1.9.1 but maybe we manage to really
> improve this and and come nearer towards the actual plan next time around.

I thought the original plan was to release smaller changes more often in
minor releases, and at the same time work on Mozilla2. But I haven't heard
anything about Mozilla2 in the last few months. But I have missed an
annoucement where it was declared dead or postponed...
Peter.

Dan Mosedale

unread,
Mar 23, 2009, 12:50:00 PM3/23/09
to
On 3/20/09 5:17 PM, jos...@gmail.com wrote:
> We're currently planning to remove OJI, LiveConnect, and the XPCOM
> plugin API from Gecko 1.9.2. We've worked hard to get to a point where
> this would be possible and I believe we can make these changes in
> Gecko 1.9.2.
>
> We are planning to remove those components because they are largely
> unmaintained, they have few consumers, and there are better
> alternatives.
>

What effect will this have on Gecko application extensions that contain
Java code? That they would need source-level changes? That they would
stop working entirely?

Dan

jos...@gmail.com

unread,
Mar 23, 2009, 6:24:08 PM3/23/09
to
On Mar 23, 9:50 am, Dan Mosedale <dm...@mozilla.org> wrote:

There are no functional regressions that I'm aware of, nor do I know
of any required code changes under the new plugin. You can even still
access Java classes from JS in the same way that it was possible
before iirc, though the details of that aren't clear to me. I don't
know much about that functionality, I just recall that it was
preserved. So as far as extensions relying on a particular Java plugin
goes, I don't think there are any issues.

Johnny Stenback

unread,
Mar 23, 2009, 8:10:03 PM3/23/09
to Justin Dolske
Justin Dolske wrote:
> Crazy idea -- turn it off now, maybe just for a week or two, and see if
> anyone screams bloody murder?

When we opened up mozilla-central (or shortly thereafter), it was turned
off (though source still in the tree), for quite some time in fact. And
worse, if a Mac user then went to a website that actually used Java,
they'd crash (IIRC we even shipped Firefox 3.1 alpha 1 with this).
Nobody really screamed then, so I don't think we'll learn much more if
we do it again now.

--
jst

Johnny Stenback

unread,
Mar 23, 2009, 8:10:27 PM3/23/09
to Justin Dolske
Justin Dolske wrote:
> Crazy idea -- turn it off now, maybe just for a week or two, and see if
> anyone screams bloody murder?

When we opened up mozilla-central (or shortly thereafter), it was turned

Johnny Stenback

unread,
Mar 23, 2009, 8:14:20 PM3/23/09
to jos...@gmail.com

There is one functional difference, and that's for binary extensions
that explicitly use the LiveConnect library in Mozilla to talk directly
from C to Java. That will no longer work, and we have no intentions to
provide equivalent functionality directly from C going forward, largely
due to lack of owners of such code, which is what got us here in the
first place.

Code that depends on such functionality basically need to either funnel
through JS to benefit from the NPRuntime layer between the browser and
Java, or ship with additional libraries that do the C to Java bridging.

--
jst

Jesper Kristensen

unread,
Mar 26, 2009, 3:59:43 PM3/26/09
to
timeless skrev:

> On Mon, Mar 23, 2009 at 5:27 AM, Igor Bukanov <ig...@mir2.org> wrote:
>> Some banks use Java for netbanking and there are photo-sharing or
>> printing sites that use signed Java applet to implement multiple image
>> upload.
>
> My bank is one of those stupid banks. (It's a subsidiary of Danske
> bank and the java requirement was introduced after Dasnke bought my
> bank, so I'd imagine it's a feature of their somewhat widely spread
> Nordic banking services).

I don't know a single bank where I live (Denmark) which does not use
Java (well, those who use ActiveX instead doesn't count)

dpk....@gmail.com

unread,
Mar 27, 2009, 5:22:16 PM3/27/09
to
On Mar 20, 8:17 pm, josh...@gmail.com wrote:
> We're currently planning toremoveOJI, LiveConnect, and the XPCOM

> plugin API from Gecko 1.9.2. We've worked hard to get to a point where
> this would be possible and I believe we can make these changes in
> Gecko 1.9.2.
>
> We are planning toremovethose components because they are largely

> unmaintained, they have few consumers, and there are better
> alternatives.
>
> To put this change in perspective in terms of a timeline, the earliest
> a browser with those changes would ship would be approximately Q2
> 2010.
>
> There are three major consumers of these components - Sun's Java
> plugin, Steven Michaud's JEP, and the Real player. Sun has worked with
> us to develop a new Java plugin based on NPAPI and NPRuntime, removing
> their dependency onOJI/LiveConnect and the XPCOM plugin API. This new

Hi,

My name is Deepak Bhole. I am the maintainer of the IcedTea Java
plugin, which is part of the IcedTea project (http://
icedtea.classpath.org/wiki/Main_Page). It is the default Java plugin
installed with Fedora, Ubuntu and other common distros, and the only
open source one afaik that supports LiveConnect.

The plugin work began a while ago, and hence uses OJI. Converting it
to npruntime would take significant efforts (pretty much a rewrite for
all intents and purposes). I understand that you worked with Sun to
remove the OJI dependence in the new plugin, but that plugin is closed
source at the moment. Would it be possible for you to reconsider
removing OJI at least until another open source option becomes
available?

Deepak

jos...@gmail.com

unread,
Mar 31, 2009, 11:41:35 PM3/31/09
to

Hi Deepak,

Thanks for getting in touch. At this point I think we are pretty
committed to removing OJI/LiveConnect in Gecko 1.9.2 but the good news
is that Firefox 3.5 should fully support your plugin for some time and
you have a while to port to NPAPI/npruntime before a Gecko 1.9.2
browser is released. I'd be happy to help with any questions you might
have.

-Josh

c2h...@gmail.com

unread,
Apr 16, 2009, 3:52:33 PM4/16/09
to
On Mar 31, 11:41 pm, josh...@gmail.com wrote:
> On Mar 27, 5:22 pm, "dpk.bh...@gmail.com" <dpk.bh...@gmail.com> wrote:
>
>
>
> > On Mar 20, 8:17 pm, josh...@gmail.com wrote:
>
> > > We're currently planning toremoveOJI,LiveConnect, and the XPCOM

> > > plugin API from Gecko 1.9.2. We've worked hard to get to a point where
> > > this would be possible and I believe we can make these changes in
> > > Gecko 1.9.2.
>
> > > We are planning toremovethose components because they are largely
> > > unmaintained, they have few consumers, and there are better
> > > alternatives.
>
> > > To put this change in perspective in terms of a timeline, the earliest
> > > a browser with those changes would ship would be approximately Q2
> > > 2010.
>
> > > There are three major consumers of these components - Sun's Java
> > > plugin, Steven Michaud's JEP, and the Real player. Sun has worked with
> > > us to develop a new Java plugin based on NPAPI and NPRuntime, removing
> > > their dependency onOJI/LiveConnectand the XPCOM plugin API. This new
> >removethe OJI dependence in the new plugin, but that plugin is closed

> > source at the moment. Would it be possible for you to reconsider
> > removing OJI at least until another open source option becomes
> > available?
>
> > Deepak
>
> Hi Deepak,
>
> Thanks for getting in touch. At this point I think we are pretty
> committed to removing OJI/LiveConnectin Gecko 1.9.2 but the good news

> is that Firefox 3.5 should fully support your plugin for some time and
> you have a while to port to NPAPI/npruntime before a Gecko 1.9.2
> browser is released. I'd be happy to help with any questions you might
> have.
>
> -Josh

Hi Josh,

Thanks for the reply. I've been in contact with the Sun team, and they
are unable to provide a release date for the plugin source. As soon as
this change goes through, bleeding edge versions of distros (like
Rawhide for Fedora) will completely lose (open source) java plugin
support.

Is there no way to atleast delay a removal a bit while we plan a
rewrite? With 3.5 due around June, that gives us only ~2-3 months
before things will start breaking, and it wouldn't be sufficient to
plan and write a new plugin from scratch given the current status of
resources...

Cheers,
Deepak

Benjamin Smedberg

unread,
Apr 16, 2009, 4:01:18 PM4/16/09
to
On 4/16/09 3:52 PM, c2h...@gmail.com wrote:

> Is there no way to atleast delay a removal a bit while we plan a
> rewrite? With 3.5 due around June, that gives us only ~2-3 months
> before things will start breaking, and it wouldn't be sufficient to
> plan and write a new plugin from scratch given the current status of
> resources...

This change is being proposed for the release *after* 3.5, which is not due
until early 2010.

--BDS

c2h...@gmail.com

unread,
Apr 16, 2009, 4:09:18 PM4/16/09
to

Hmm, that is what I originally thought too, but then I read that 3.1
is being renamed to 3.5 (https://developer.mozilla.org/devnews/
index.php/2009/03/06/shiretoko-to-be-named-firefox-35/).. which is due
out in June 09. Is the 3.5 that the original email refers to, actually
3.6 (now, after the 3.1->3.5 rename) then?

Mike Shaver

unread,
Apr 16, 2009, 4:11:43 PM4/16/09
to Benjamin Smedberg, dev-pl...@lists.mozilla.org
I believe the concern is that the rawhide-y distros package our trunk
at various intervals, and would thus lose Java capability for at least
one of the JVMs they ship once we land these changes (after we finish
3.5).

I didn't realize that Sun's plugin wasn't open source -- curious, and
unfortunate.

Mike

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>

--
Sent from Gmail for mobile | mobile.google.com

c2h...@gmail.com

unread,
Apr 16, 2009, 4:24:52 PM4/16/09
to
On Apr 16, 4:11 pm, Mike Shaver <mike.sha...@gmail.com> wrote:
> I believe the concern is that the rawhide-y distros package our trunk
> at various intervals, and would thus lose Java capability for at least
> one of the JVMs they ship once we land these changes (after we finish
> 3.5).
>

Yes, that is my concern. Rawhide is always bleeding edge, and will
switch to using trunk soon after 3.5 is out, and that will break all
Java plugin support in the process.

> I didn't realize that Sun's plugin wasn't open source -- curious, and
> unfortunate.
>

The new plugin will be open sourced at some point once it makes to
OpenJDK 7:
http://openjdk.java.net/projects/jdk7/features/#f647

As early as June/July if that target is achieved. Unfortunately, given
the unknown status at this time, I am not sure how reliable that date
is.

Cheers,
Deepak

> Mike


>
> On 4/16/09, Benjamin Smedberg <benja...@smedbergs.us> wrote:
>
>
>
> > On 4/16/09 3:52 PM, c2h...@gmail.com wrote:
>
> >> Is there no way to atleast delay a removal a bit while we plan a
> >> rewrite? With 3.5 due around June, that gives us only ~2-3 months
> >> before things will start breaking, and it wouldn't be sufficient to
> >> plan and write a new plugin from scratch given the current status of
> >> resources...
>
> > This change is being proposed for the release *after* 3.5, which is not due
> > until early 2010.
>
> > --BDS
> > _______________________________________________
> > dev-planning mailing list

> > dev-plann...@lists.mozilla.org

Reply all
Reply to author
Forward
0 new messages