MozillaWiki

Update:Archive/2.0/Developers: Difference between revisions

Update Discussion

Update:Archive/2.0/Developers (view source)

Revision as of 04:47, 29 April 2007

2,304 bytes added ,  29 April 2007
m
Update:Development:v2.0 moved to Update:Archive/2.0/Developers
 
(42 intermediate revisions by 13 users not shown)
Line 1: Line 1:
[[Update:Home_Page|Update: Home Page]] » [[Update:Development|Development]] »
[[Update:Home_Page|Update: Home Page]] » [[Update:Development|Development]] »


== UMO v2.0 Goals ==
== v2.0 Goals ==
* security
* security
* reliability
* reliability
Line 7: Line 7:
* reputation
* reputation
* communication
* communication
* localization


Using sound teamwork, we will develop a secure, robust, extendible application that will bolster the success of the Mozilla Foundation and the community it supports.
Using sound teamwork, we will develop a secure, robust, extensible application that will bolster the success of the Mozilla Foundation and the community it supports.
 


== Team ==  
== Team ==  
Line 23: Line 23:
* morgamic
* morgamic


== Tentative Timeline ==
== Project Outline ==
# Planning / Requirements (April 20-30)
# Planning / Requirements
## Project Standards
## Project Standards
## Database Considerations
## Libraries and Tools
## Application Structure
## Application Structure
## Libraries and Tools
# Development
# Development (May-June)
## Admin Tools
## Editor/Developer Tools
## Addons
## AUS
## PFS
## Public Pages  
## Public Pages  
# Staging (June 21-June 27)
## Developer Tools
# Debugging (July 1-July 14)
# Staging
# Beta Release (July 17)
# Debugging
# Beta Release


== Project Standards ==
== Project Standards ==
Line 44: Line 39:


=== Language ===
=== Language ===
We are going to stick with PHP and make the new code base work with PHP 4.3.x.  We considered PHP 5.0 but felt that it did not tie in well with the existing MoFo infrastructure.  We also considered several other alternatives but in the end felt that the existing skill set and the ability to get up to speed quickly with PHP were the keys to success here.
'''[http://php.net/ PHP 4.3.x]'''.  PHP 5.0 does not tie in well with the existing MoFo infrastructure.  We did consider alternatives.


=== Templating ===
=== Template Engine ===
We are going to use [http://smarty.php.net Smarty] for our template engine.  People considered writing our own but it was all a question of recreating what Smarty already did.
'''[http://smarty.php.net Smarty]'''.  It is widespread and easy to implement.


=== Database Abstraction ===
=== Database Abstraction ===
PEAR::DB (http://pear.php.net/package/DB ) is going to be our database abstraction layer. We chose this because it is part of the PEAR suite and it's likeness to Perl's DBI.
'''[http://pear.php.net/package/DB PEAR::DB]'''. A standard part of the PEAR suite with likeness to Perl's DBI.


=== Database Server ===
=== Database Server (RDBMS) ===
We are sticking with the MoFo standard here: MySQL 4.1.
'''[http://dev.mysql.com/doc/mysql/en/index.html MySQL 4.1]'''.


=== Licensing ===
=== Licensing ===
Line 59: Line 54:


=== Coding Standards ===
=== Coding Standards ===
We are going to stick with the standard Mozilla coding standards where they apply and then [[Update:Development:Best Practices|develop our own]] where they do not.
'''[http://pear.php.net/manual/en/standards.php PEAR Coding Standards]'''. This standards guide is fairly standard fare for PHP applications.
 
We will do our best to adhere to the Mozilla coding standards. Since not many Mozilla projects are written in PHP, we have [[Update:Development:Best Practices|developed our own]] where necessary.
 
== TODO ==
* [http://lxr.mozilla.org/mozilla/source/webtools/addons/lib/session.class.php lib/session.class.php]
** [https://bugzilla.mozilla.org/show_bug.cgi?id=312629 simple session handler based on sid.]
* lib/auth.class.php
** simple session checker and auth module.
** PEAR::Auth?
* [http://lxr.mozilla.org/mozilla/source/webtools/addons/addcomment.php addcomment.php] - Colin
** form
** spam prevention - '''require login'''
** input validation
* <strike>[http://lxr.mozilla.org/mozilla/source/webtools/addons/addon.php addon.php]</strike>
** <strike>sidebar</strike>
** show compat information
* [http://lxr.mozilla.org/mozilla/source/webtools/addons/history.php history.php] - Colin
** show all past versions - initially done but needs improvement...
** simplify?
* <strike>index.php</strike>
** <strike>make it look more like overview.php?</strike>
* previews.php - Colin
** <strike>Show all Addon previews.</strike>
* ratecomment.php - Colin
** spam prevention '''This needs to be thought about'''.
** <strike>other than that, this is a simple toggle script.</strike>
** <strike>login isn't required for this particular page.</strike>
* search.php
** [https://bugzilla.mozilla.org/show_bug.cgi?id=277851 highlight search results]
** <strike>Create search form based on DB.</strike>
** <strike>Filter inputs.</strike>
** <strike>Document needed options.</strike>
** <strike>Create jump-to for one-result searches.</strike>
* header / footer / style
** Fix key-menu so that it is simplified.  Each app link should be a tab, instead of offering 3 different choices per.
** <strike>Make the search stick out more -- this is a key feature of this site.</strike>
** <strike>Make sure CSS changes work in multiple browsers.</strike>
* addon.class.php
** <strike>Move manual queries in constructor to respective functions (i.e. getLatestVersion() instead of a hard query)</strike>


== Use-cases and Requirements ==
== Use-cases and Requirements ==
Line 82: Line 116:


:All (Wiki) content indicated above should be part of the main site, in my opinion. The wiki shouldn't be used for anything 'official' to do with the site, it is a lot easier to get an account and maliciously edit pages on the wiki than it would be to maliciously edit pages on the main site. --[[User:Csogilvie|Colin]] 16:10, 15 Jun 2005 (PDT)
:All (Wiki) content indicated above should be part of the main site, in my opinion. The wiki shouldn't be used for anything 'official' to do with the site, it is a lot easier to get an account and maliciously edit pages on the wiki than it would be to maliciously edit pages on the main site. --[[User:Csogilvie|Colin]] 16:10, 15 Jun 2005 (PDT)
:How about a "my favorite extensions" section with details of latest versions and comments. Users could then "bookmark" extensions they're interested in, but might not have installed. It could also automatically keep track of extensions installed, and visted but uninstalled extensions (something like Google's My Search History). It might encourage more users to register as it's providing something of value to them. Stats could be used for recomendations. You could also track which extensions are being removed from peoples favorites. --[[User:Sam Hasler|Sam]] 14:25, 17 Jun 2005 (PDT)
:Heh. No one has written here in awhile.
Maybe I'm missing something, but the main page right now doesn't even have links to look for TB extensions, or extensions for any other Moz apps besides FF. Clicking on the extensions button on the front page automatically takes you into a page showing FF extensions. So... is there no way to get to TB extensions without either going through TB or doing some sort of search?
--[[User:Wjjohnst|DigDug] 22:20 05 Oct, 2006


==== Search By... ====
==== Search By... ====
Line 96: Line 138:
==== Results List ====
==== Results List ====
* Allow ASC or DESC sorting per category via clicking on column header
* Allow ASC or DESC sorting per category via clicking on column header
* Allow user to choose compact or expanded view (expanded is what UMO shows now)
* Allow user to choose compact or expanded view
* Expanded -- Show everything UMO shows now
** Compact -- Show only vital items, all in one row, text-only
* Compact -- Show only vital items, all in one row, text-only
** Expanded -- Show everything UMO shows now
* Give user a link to Download/Install or view Item Home page
* Give user a link to Download/Install or view Item Home page


Line 106: Line 148:


:so, this means we need to use a column-type display for the results.  I'm not sure if that's always good.  Maybe only use it for advanced searches, but quicksearch gets the current-style result list? --[[User:CTho|CTho]] 19:05, 13 Jun 2005 (PDT)
:so, this means we need to use a column-type display for the results.  I'm not sure if that's always good.  Maybe only use it for advanced searches, but quicksearch gets the current-style result list? --[[User:CTho|CTho]] 19:05, 13 Jun 2005 (PDT)
I would go for search results that have an extended result by clicking on an image with the "more" concept. Those extended results would be hidden in DIVs that will be shown bellow the line of the extension summary when the user clicks the "more" image. This is client side or if we want smaller pages we can use AJAX to bring this extended content when needed. --[[User:DonGato|DonGato]] 11:57, 28 Nov 2006 (GMT)


==== Item Home ====
==== Item Home ====
* Item home must contain:
* Item home must contain:
** Item previews and screenshot thumbnails
** Item previews and screenshot thumbnails
** Links to all previews and screenshots
** Links:
** Link to Item revision history
*** Download/Install<br><br>
** Link to Item author information
*** Revision history
** List of highest user-rated (helpful) comments
*** Author information
** Link to add a comment
*** View all previews/screenshots<br><br>
** Link to view all comments
*** View all comments
** Link to rate comments, shown with comment
*** View comments which were rated most helpful by users
** Link to Download/Install
*** Rate comment's helpfulness (shown with a given comment)
*** Add a comment
 
[why not initially base these specs on what already exists on the current UMO site item-home page, and include everything which is on that page?]


==== Comments / Reviews ====
==== Comments / Reviews ====
Line 126: Line 173:


:this is getting into metamoderation, which needs more discussion.  -alanjstr 2005-06-01 14:16 EST
:this is getting into metamoderation, which needs more discussion.  -alanjstr 2005-06-01 14:16 EST
:Further to the discussion on #umo, I'm thinking we need some sort of trackability as with the approval log for comment reviewers. This gives a degree of accountability that we can fall back on if necessary.
:We also need to prevent reviewers that are also developers from moderating the comments on their own extension.
:Also, some sort of threadability would be useful so that you would be able to directly reply to comments in a sort of 'forum style'. This of course may not be necessary if we actually do build in a forum type system (possibly in collaboration with extensionsmirror.nl) but as I understood it, this has not been agreed yet. --[[User:Chrisblore|Chrisblore]] 13:54, 27 Jun 2005 (PDT)


==== Adding a New Comment ====
==== Adding a New Comment ====
Line 158: Line 209:
:if the user is logged in, can we store this on the server?  What if a user has TB and FX?  Can we save both?  I'd skip app version and just track app/OS, assuming that most people will upgrade. -alanjstr 2005-06-01 14:16 EST
:if the user is logged in, can we store this on the server?  What if a user has TB and FX?  Can we save both?  I'd skip app version and just track app/OS, assuming that most people will upgrade. -alanjstr 2005-06-01 14:16 EST


==== Content outsourced to Wiki ====
==== Supporting Site Content ====
* about UMO...
* About UMO
* Updates / news
* News
* FAQ and support documentation
* FAQ
* Developer policies and guide
* Policy
* Reviewer policies and guide
* Developer policies and guide - Wiki
* Reviewer policies and guide - Wiki


:'''Comments'''
:'''Comments'''
Line 171: Line 223:


:Policies should be read-only, signed off by legal, and posted on the site.  Everything else can be in the wiki. -alanjstr 2005-06-01 14:16 EST
:Policies should be read-only, signed off by legal, and posted on the site.  Everything else can be in the wiki. -alanjstr 2005-06-01 14:16 EST
:I agree with your comments.  Guides, however, are constantly updated and should be placed in a Wiki where they can be maintained.  They are relatively dynamic in nature and placing them in the application itself would be very limiting. -[[User:morgamic|morgamic]]


=== Developers ===
=== Developers ===
Line 376: Line 430:
=== Administrators ===
=== Administrators ===
* Administrators should basically have all the general functionality of all other user groups, with added rights to _all_ records and the ability to edit/bless user accounts.
* Administrators should basically have all the general functionality of all other user groups, with added rights to _all_ records and the ability to edit/bless user accounts.
* It's currently too hard to create new reviewers - it requires receiving an email (the intial request), replying to tell the user to create an account, waiting for the reply, then granting them Editor privileges.  This should be streamlined - maybe just a "Volunteer to be a reviewer" button on the developer pages?  --[[User:CTho|CTho]] 17:58, 4 Oct 2005 (PDT)


=== Systems ===
=== Systems ===
Line 382: Line 437:


== Database Structure ==
== Database Structure ==
=== v1.0 Schema ===
'''v2.0 will be rewritten using [https://update-staging.mozilla.org/~colin/dev/ the existing database structure].'''
Thanks to Colin for helping make the [https://update-staging.mozilla.org/~colin/dev/ v1.0 diagram].
 
Thanks to Colin for drawing up the diagram.


==== Problems ====
==== Known Issues ====
* Lacks proper normalization
* Lacks proper normalization
* Incorrect typing
* Incorrect typing
* Non-optimal indexing
* Non-optimal indexing
* Non-optimal version comparisons
* Non-optimal version comparisons
* Inconsistent nomenclature
* Others... ?
=== v2.0 Schema ===
The [http://oregonstate.edu/~morgamic/umo/umo.png first draft of the v2.0 schema] was drafted at midnight, 05/18.
It was made with [http://www.graphviz.org/ GraphViz]; [http://oregonstate.edu/~morgamic/umo/umo.txt view the source file].
==== Change Log ====
* Removed
** faq - outsource to wiki, bring back later if needed
** feedback_ipbans - user accounts will be required for comment posts, general throttling enabled makes this unnecessary
:::see my comment above regarding registration for comments --[[User:CTho|CTho]] 19:24, 13 Jun 2005 (PDT)
** approvallog - this is replaced by reviews
** downloads - this is just deleted, replaced by singular column in addon_versions (throttling, remote limitations pending of course)
* Added
** sessions - track user sessions with more detail, also ensure sess data integrity
** app_addon_map - mappings between addon versions and app versions, replacing minver/maxver comps with a simpler query
** os_addon_map - mappings between addon versions and operating systems, abstracted to avoid having to hard-code OS id's in UMO application (as in v1.0)
** reviews - per-user/per-os review logs, added N times until approval so each item in queue has a running total of "what has been looked at"
** comments - replaces feedback, and is now mapped to user_id (login required)
** addon_types, addon_type_map - abstracts addon types, so E/T will no longer be hard-coded in UMO application (as in v1.0)
** locales, locale_addon_map - per-addon (not per addon version) locale information to help with international extension or theme searches
:What if they have one XPI for EN and one XPI for FR? -alanjstr 2005-06-01 14:36 EST
:I don't see how you could query for a minver or maxver at all here.  There's only one field, not two for min and max.  There is not table of app versions. -alanjstr 2005-06-01 14:36 EST
*General Changes
** naming consistency
** better normalization (probably too much, and probably not perfect, but it's a start)
** better fits workflow
==== Colin's Comments ====
The schema seems reasonable as it stands, although some changes are likely to be necessary pending the discussion above regarding FAQs etc. and whether they should be part of this site, not the Wiki.
Other points as follows:
* It seems comments are per addon version and not per addon? This seems 'wrong' to me.
* Each addon_version should (perhaps) have a an "approved_time" column, so that the "Newest" Extensions are based on approved time rather than than added time (which could be 5 days earlier)
==== Possible Problems with this draft ====
* over-normalization
* lack of download spam checking in DB (still could be mitigated with proper app logic)
* requiring login for comments might suck, would require a left-join if user_id stays
* migration will be painful, but it is probably a necessary pain (open for discussion, guys)
== Application Structure  ==
<pre>
INSTALL
README
dev
    apps.php
    appadd.php
    appedit.php
    appdelete.php
    comments.php
    commentedit.php
    commentdelete.php


    items.php
These issues will be worked on over time. They are not, however, so serious that a complete restructuring is required for v2.0.
    itemadd.php
    itemedit.php
    itemhistory.php


    users.php
==== Garbage ====
    useradd.php
For fun, here is the [http://oregonstate.edu/~morgamic/umo/umo.png now-obselete  v2.0 db diagram] (05/18). It was made with [http://www.graphviz.org/ GraphViz]; [http://oregonstate.edu/~morgamic/umo/umo.txt view the source file].
    useredit.php
    userdelete.php
inc
    init.php
    config-dist.php
    config.php
img
    <global images>
lib
    pear
    smarty
    modules
        user.inc.php
        item.inc.php
        comment.inc.php
        xpi.inc.php
        rss.inc.php
        pfs.inc.php
        vck.inc.php
pub
    rss
        index.php
    pfs
        index.php
    vck
        index.php
    commentadd.php
    commentrate.php
    history.php
    index.php
    list.php
    advancedsearch.php
    item.php
sql
    umo.sql
themes
    default
        img
        css
            screen.css.php
        layout.inc.php
tmpl
    dev
        appform.tpl.php
        filter.tpl.php
        itemform.tpl.php
        list.tpl.php
        userform.tpl.php
    pub
        commentadd.tpl.php
        history.tpl.php
        list.tpl.php
        view.tpl.php
    common
        footer.tpl.php
        header.tpl.php
        navbar.tpl.php
        search.tpl.php
</pre>


:Is .php the proper extension for screen.css.php and *.tpl.php?  -alanjstr 2005-06-01 14:30 EST
== Application Structure ==
; .htaccess : Set up include_path, prepend and append options.
; addcomment.php : Add a new comment.
; ratecomment.php : Rate an existing comment.
; comments.php : View comments for an addon.
; css/ : CSS layout and formatting.
; developers : Developer tools used by developers, reviewers and admins.
; faq.php : Frequently Asked Questions.
; history.php : View an addon's previous versions.
; img : Site images.
; inc : Site includes.  config.php, init.php, finish.php.
; index.php : Main page.
; addon.php : An addon's main page.
; lib : Supporting library and class files.
; LICENSE : Application license.
; README : Installation instructions for site developers.
; previews.php : Addon previews.
; rss : Syndicated information for addons based on type and application.
; search.php : Search for addons using a simple search, or expand simple search to refine your search.
; sql : Application database structure.
; tpl : Smarty templates placed in this directory are '''used for all output'''.


== Expected Behavior (client-side) ==
== Expected Behavior (client-side) ==
Line 529: Line 483:
** No results (3)
** No results (3)
** Client extension version is greater than anything in UMO database (4)
** Client extension version is greater than anything in UMO database (4)
** Downloaded .xpi does not match reported size (5)
* There is a need client-side to implement better update features for addons, similar to those found in [Software Update].  In particular, hash checking and improved error handling (for errors above) would be great additions.


: What about "Client extention version file size does not match reported size?" --[[User:Blind487|Blind487]] 16:51, 30 May 2005 (PDT)
== UI Tweaks ==
* Alignment of title / drop-down on 'Search Options' sidebar would look better uniform (columned).
* Blue bar at the top (below 'mozilla update' text) looks incredibly empty, especially towards the right. If it's going to remain empty, perhaps consider moving the search to the right.
* Tabs on home page
** Incredibly plain / square.
** Blue on inactive tabs doesn't really fit with the rest of the UI.
** Perhaps consider using the same style tabs as on the header of this wiki?
Fligtar
canmove, Confirmed users, Bureaucrats and Sysops emeriti
1,043

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/8547...55479"