|
|
(7 intermediate revisions by 3 users not shown) |
Line 1: |
Line 1: |
| [[Update:Home_Page|Update: Home Page]] » Architecture and General Design
| | {{AmoArchive}} |
|
| |
|
| This document will describe the overall architecture of the UMO services in detail. It should include sub-sections on pfs, addons, etc. that will be populated by the developers working on those components. | | This document will describe the overall architecture of the UMO services in detail. It should include sub-sections on pfs, addons, etc. that will be populated by the developers working on those components. |
|
| |
|
| == Addons.Mozilla.Org End-User Website == | | == Addons.Mozilla.Org End-User Website == |
| === Architecture ===
| |
| ==== Main - Items that are common between versions ====
| |
| * ID - Database identifier used to tie tables together
| |
| * GUID - Unique identifier from inside the install.rdf. Allows the application and the website to talk about the same thing
| |
| * Name - Name of the addon
| |
| * Type - Enumerator (T/E/P) that specifies if the listing is a theme, extension, or plugin
| |
| * Date Added - Date the item was submitted to the website
| |
| * Homepage - Website for the submission
| |
| * Description - Description of the addon
| |
| * Rating - Accumulated rating
| |
| * Download Count - ?
| |
| * Total Downloads - ?
| |
| * Developer's Comments - Additional comments by the developer
| |
|
| |
|
| ==== Version - Details for each file on the site (one row per app/os) ====
| | Addons serves as the main point of interaction for developers and end-users to get extensions and themes for their Mozilla products. |
| * ID - Database identifier
| |
| * Version - Version string x.x.x.x
| |
| * OSID - Database identifier linking compatibility with Operating Systems
| |
| * AppID - Database identifier linking compatibility with Applications
| |
| * MinAppVer - Minimum version of the supported application
| |
| * MinAppVer_int - Internal numbering of the minimum version
| |
| * MaxAppVer - Maximum version of the supported application
| |
| * MaxAppVer_int - Internal numbering of the maximum version
| |
| * Size - size of the file in kilobytes
| |
| * Date Added - Date version was added
| |
| * Date Updated - Date information about the version last changed
| |
| * URI - Download URI
| |
| * Notes - Release notes/changelog
| |
| * Approved - Enumerator (Yes/No/Disabled) used to show whether it has been approved to be listed
| |
|
| |
|
| ==== Userprofiles - Details for each user ==== | | === Overview === |
| * UserID - Database Identifier
| |
| * User Name - Name or nickname for users
| |
| * User Email - Email address
| |
| * User Website - User's website
| |
| * User Pass - Password
| |
| * User Mode - Enumerator (A/E/U/D) reprsenting whether the user is an Administrator, Editor, Developer, or Disabled
| |
| * User Trusted - Determines whether user is allowed to bypass approval queue
| |
| * User Email Hide - Does the user wish to disclose their email address on their public profile
| |
| * User Last Login - Last time the user logged in
| |
| * Confirmation Code - ?
| |
|
| |
|
| ==== AuthorXref - Relates Addons to their Authos ====
| | * DocumentRoot: /opt/update |
| * ID - Main ID | | * URL: addons.update.mozilla.org |
| * User ID - Author ID | | * URL: addons.mozilla.org -> redirect to addons.update.mozilla.org (fix for FF 1.0 whitelist) |
| | * Type of content: PHP intensive, very dynamic |
| | * Example request: N/A |
|
| |
|
| ==== Categories - Allows grouping of Addons ==== | | === Questions === |
| * Category ID - Database Identifier
| |
| * Cat Name - Name of Category
| |
| * Cat Desc - Description
| |
| * Cat Type - Enumerator (T/E/P) specifying whether this category is for Themes, Extensions, or Plugins
| |
| * Cat App - Name of the application the category applies to
| |
|
| |
|
| ==== File Repository ====
| | * How do extension files get to the mirrors? |
| The following directory structure should be created and given write permissions:
| | * Can we get Firefox to point at this URL for 1.0.1? |
| * /
| |
| ** files
| |
| *** approval | |
| **** extensions
| |
| **** themes
| |
| *** ftp
| |
| *** temp
| |
|
| |
|
| | == Plugin Finder Service == |
|
| |
|
| ==== CategoryXref ====
| | This plugin helps Firefox find plugins it needs to do stuff. Again, we have the huge long URL with unique information in it. Can we fix that? This is a perfect application to leverage caching -- data doesn't change much. |
|
| |
|
| ==== OS ==== | | === Overview === |
|
| |
|
| ==== Approval Log ==== | | * DocumentRoot: /opt/update |
| | * URL: pfs.mozilla.org |
| | * Type of content: PHP intensive, mildly dynamic |
| | * Example request: <nowiki>https://pfs.mozilla.org/plugins/PluginFinderService.php?mimetype=application/x-shockwave-flash&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=2004112212&clientOS=Windows%20NT%205.1&chromeLocale=de-DE</nowiki> |
|
| |
|
| ==== Downloads ==== | | === Questions === |
|
| |
|
| ==== FAQ ====
| | * Can we get Firefox to point at this URL for 1.0.1? |
| | * We have got to get Flash off of the UMO servers -- accounts for 53% of traffic right now. |
|
| |
|
| ==== Feedback ==== | | == Application Update Service == |
|
| |
|
| ==== Previews ====
| | This is the section of the UMO service that actually allows specific applications to check if they need to be upgraded. |
|
| |
|
| ==== Reviews ==== | | === Overview === |
|
| |
|
| == Plugin Finder Service ==
| | * DocumentRoot: /opt/update |
| | * URL: aus.mozilla.org |
| | * Type of content: Completely static |
| | * Example request: http://aus.mozilla.org/update/firefox/en-US.rdf |
|
| |
|
| (this is for jst)
| | === Questions === |
| | |
| == Application Update Service == | |
|
| |
|
| == Infrastructure ==
| | * Can we get Firefox to point at this URL for 1.0.1? |
| [[Update:Architecture_and_General_Design:Infrastructure|Infrastructure]]
| | * What if this was generated with the UMO toolset and then pushed to several machines designed for delivering static content? |
| | * Can we return a base URL for Firefox/Thunderbird to chew on? |
| | * Can we better leverage/integrate with the bouncer so as to not overload the mirror network? |