Closed
Bug 465898
Opened 16 years ago
Closed 14 years ago
Rearchitect plugin finder service
Categories
(Websites :: plugins.mozilla.org, defect)
Websites
plugins.mozilla.org
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: morgamic, Assigned: lorchard)
References
Details
Tracking bug for all PFS rearch work. The general ideas and goals are covered here:
https://wiki.mozilla.org/Plugins:ImpovementPlan
https://wiki.mozilla.org/User:Mconnor/PluginBlocklisting
Deliverables:
* revised plugin schema to store all plugin data
* new service that provides xml and json output
* javascript library to embed pfs functionality in any site for plugin awareness
Reporter | ||
Updated•16 years ago
|
Blocks: upyourplug
Reporter | ||
Updated•16 years ago
|
Target Milestone: 4.0.5 → 5.0.1
Reporter | ||
Updated•16 years ago
|
Target Milestone: 5.0.1 → 5.0.2
Reporter | ||
Updated•16 years ago
|
Assignee: nobody → morgamic
Comment 1•16 years ago
|
||
any parts of this planned for q1?
Reporter | ||
Comment 2•16 years ago
|
||
Yes, implementation of server-side script will be done in Q1. Not sure if we'll be able to finish the JS API, so looking for help on that.
Comment 3•16 years ago
|
||
http://www.techzoom.net/publications/insecurity-iceberg/index.en has some good insight and perspective into why this is needed, and points out issues around trying to set something up and keep it maintained.
In particular "4.2.2 Authentic sources of most recent plug-in versions" suggests some standard/authentic sources that could be used across browsers and websites to determine if users are running plugins that are safe. This might be close to qualifying as one of those authentic sources.
One of the problems will be with trying to keep it updated with current info. Are we thinking about access controls to this database that would allow the plugin vendors to maintain current version info, or are we thinking it will be maintained by mozilla contributors that will need to track each of the plugin vendor releases?
Comment 4•16 years ago
|
||
one other thought is that if this is to become an updating system used widely by plugin vendors it might need some of the features we use to effectively manage updates of firefox. those might include
-update channels for various versions and target audiences
-major update mechanisms
-throttling to control the presentation of update info and control bandwidth use
All of this is way more than we do now but it might help to think about how we might add these to the initial design so we could add later if needed.
Updated•16 years ago
|
Target Milestone: 5.0.2 → 5.0.3
Updated•16 years ago
|
Target Milestone: 5.0.3 → ---
Assignee | ||
Comment 5•15 years ago
|
||
Anyone happen to have the content from this wiki page:
https://wiki.mozilla.org/Plugins:ImpovementPlan
Not sure if it's still relevant, but it's another one that got deleted...
Updated•15 years ago
|
Assignee: morgamic → lorchard
Reporter | ||
Comment 6•15 years ago
|
||
I don't have it -- I'd consider it long gone.
Comment 7•15 years ago
|
||
https://wiki.mozilla.org/Plugins:ImpovementPlan restored now
Comment 8•15 years ago
|
||
(In reply to comment #7)
> https://wiki.mozilla.org/Plugins:ImpovementPlan restored now
typo ^^
Reporter | ||
Comment 9•15 years ago
|
||
If it's out of date and nobody is going to update it, I'm okay with it being gone.
Reporter | ||
Comment 10•15 years ago
|
||
Or, let's put it this way -- can someone update it? Chris?
Updated•15 years ago
|
Component: Plugins → plugins.mozilla.org
Product: addons.mozilla.org → Websites
Version: 3.2 → unspecified
Comment 11•14 years ago
|
||
Marking this as fixed, basic work on PFS2 has been completed, will open other bugs as necessary.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•