Update:Archive/2.0/Developers

From MozillaWiki
Jump to navigation Jump to search

Update: Home Page » Development »

UMO v2.0 Goals

  • security
  • reliability
  • extensibility
  • reputation
  • communication

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.


Team

  • bsmedberg
  • chip
  • chrisblore
  • Colin
  • CTho
  • justdave
  • kveton
  • luser
  • mao
  • morgamic

Tentative Timeline

  1. Planning / Requirements (April 20-30)
    1. Project Standards
    2. Database Considerations
    3. Application Structure
    4. Libraries and Tools
  2. Development (May-June)
    1. Admin Tools
    2. Editor/Developer Tols
    3. Addons
    4. AUS
    5. PFS
    6. Public Pages
  3. Staging (June 21-June 27)
  4. Debugging (July 1-July 14)
  5. Beta Release (July 17)

Project Standards

The following describes the standards and tools we'll be using for the v2.0 rewrite of UMO.

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.

Templating

We are going to use Smarty for our template engine. People considered writing our own but it was all a question of recreating what Smarty already did.

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.

Database Server

We are sticking with the MoFo standard here: MySQL 4.1.

Licensing

The original UMO uses a triple license: MPL 1.1/GPL 2.0/LGPL 2.1. We will continue to do the same for v2.0 of UMO.

Coding Standards

We are going to stick with the standard Mozilla coding standards where they apply and then develop our own where they do not.

Use-cases and Requirements

Users

User Use-Case Diagram

Main Page

  • Search
  • Featured items
  • Short blurb about UMO
  • Links
    • Developers section
    • About (Wiki)
    • FAQ (Wiki)
    • Affiliates (Wiki)
    • MoFo
I think we should have shortcuts like we have today for items such as Firefox Extensions and Firefox Themes. You'd hover over the application "tab" and then see what's available for it show up in the next row. -alanjstr 2005-06-01 14:10 EST
I disagree on the hovering part... it seems like it'd be nonobvious that you have to hover. --CTho 19:02, 13 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. --Colin 16:10, 15 Jun 2005 (PDT)

Search By...

  • Application [all]
  • Application Version [newest]
  • Category [any]
  • Keyword [blank]
  • Date [this week]
  • Operating System [any]
  • Locale? [en-us]
Date of what? What do you mean by "this week". -alanjstr 2005-06-01 14:12 EST

Results List

  • 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)
  • Expanded -- Show everything UMO shows now
  • Compact -- Show only vital items, all in one row, text-only
  • Give user a link to Download/Install or view Item Home page

We could alternatively use hover-divs to show item details when a user mouses over a simpler list... just an idea. An example of this would be the hover features found in WebCalendar (http://webcalendar.sourceforge.net/demo/week.php)

sorting is fine as long as we're not resubmitting. We should take advantage of DHTML here. An option to expand each/all would be good. I'm not a fan of hover-overs. What about pagination? Are we going to show 1000 on one page? -alanjstr 2005-06-01 14:14 EST
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? --CTho 19:05, 13 Jun 2005 (PDT)

Item Home

  • Item home must contain:
    • Item previews and screenshot thumbnails
    • Links to all previews and screenshots
    • Link to Item revision history
    • Link to Item author information
    • List of highest user-rated (helpful) comments
    • Link to add a comment
    • Link to view all comments
    • Link to rate comments, shown with comment
    • Link to Download/Install

Comments / Reviews

  • Complete listing of all comments
  • Sort by date or user rating
  • Link to rate comments, shown with comment
  • Link to add a new comment
this is getting into metamoderation, which needs more discussion. -alanjstr 2005-06-01 14:16 EST

Adding a New Comment

  • Encourage account registration
  • Current rate limiting enough? Captcha? Thoughts?
Comments
I think it would be a good idea to have a preview of some sort for comments prior to their submission. While we are only dealing with plain text, it can increase the quality of the comments if people actually have the opportunity to double check their typing as it will appear when submitted. Bug 295322 was filed by someone requesting this.--Chrisblore 07:51, 24 May 2005 (PDT)
encourage ... or force registration? I agree that we should make them preview. It will also help throttle anyone running amuck. -alanjstr 2005-06-01 14:17 EST
if we don't require registration, we need a reasonable way to handle abusers. requiring registration would discourage abuse, but also probably discourage people who don't want to bother signing up. if we require a confirmation email, that would REALLY discourage quick commenters (e.g. someone downloads it, likes it, and wants to say, "cool!" but isn't willing to put up with registration or email confirmations) --CTho 19:09, 13 Jun 2005 (PDT)

Item Author Information

  • Same as current
please document anyways -alanjstr 2005-06-01 14:12 EST

Item Version History

  • Same as current
please document anyways -alanjstr 2005-06-01 14:12 EST

User Preferences

  • Set preferred OS
  • Set default application
  • Set default application version
  • Set default locale?
  • Set default view for listings (per-page, etc.)
  • Other cookie-based options?
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

  • about UMO...
  • Updates / news
  • FAQ and support documentation
  • Developer policies and guide
  • Reviewer policies and guide
Comments
I disagree with outsourcing most, if not all of this to a Wiki. I believe that pages about a site, updates and news about a site and FAQs about a site should be on the site in question. I'd also expect policies about a site to be on the site in question too. --Colin 09:42, 18 May 2005 (PDT
As would I. It's much easier to keep track of documents as well if they are on the same site. We need to make sure that the developer and reviewer guides are available directly and easily from their respective control panels.--Chrisblore 06:50, 22 May 2005 (PDT)
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

Developers

Developer Use-Case Diagram

Up for discussion is:

  • Where if at all to insert locale support... ?
  • How are we going to tie-in to mentioned forums?
    • Would it not be simpler just to have a link? --Colin 16:08, 15 Jun 2005 (PDT)
Should be able to see the review queue -alanjstr 2005-06-01 14:38 EST

Edit Author profile

  • Username
  • Name
  • Homepage
  • Email (optional)
Email should be required, and should be valid IMO. --Colin 07:50, 24 May 2005 (PDT)
Email should be required and compulsarily shown in my opinion as it makes it possible to contact the authors privately about their extensions without having to use the content system --Chrisblore 03:41, 25 May 2005 (PDT)
I agree. email should always be required. We should have a bullet point for being on the mailing list. Also, any change of email address must be verified before further action can be taken. -alanjstr 2005-06-01 14:28 EST
What is the need for Real Name? -alanjstr 2005-06-01 15:14 EST
So it can be shown on the extension page - much nicer than the email address. --Colin 12:15, 7 Jun 2005 (PDT)
  • Show Email (yes|no)
  • Link to passwd change
Change Password
  • Simple chpw, as a new page or integrated -- either way
  • Verify it, also do not allow stupid passwords...

Create a new Addon

  1. Upload file
  2. Check details, choose category, etc.
    1. Name
    2. Authors
    3. Version
    4. OS
    5. Filename (read only)
    6. Applications: [minver] - [maxver] -- maxver should allow future versions as well (verify that minver < maxver)
    7. Homepage (url, use regexp)
    8. Description (bbcode)
    9. Version Notes (bbcode)
    10. Categories (multiple)
  3. Submit to queue
  4. Confirmation
We should pull as much of this from the install.rdf as possible. We should also determine whether it is an extension or theme based on the install.rdf. -alanjstr 2005-06-01 14:30 EST
Agreed, pulling as much from the RDF as possible would be useful. --Colin 12:17, 7 Jun 2005 (PDT)
Maxver should still be controlled by the admins. We just need to stay further ahead of the game. -alanjstr 2005-06-01 14:30 EST
Should allow multiple OSes without forcing OS ALL -alanjstr 2005-06-01 14:33 EST
Agreed --CTho 19:17, 13 Jun 2005 (PDT)
If addon authors are allowed to set maxver to future versions, many will just set it to a nominal large number such as 5.0, which will confuse some users into thinking Firefox 5.0 actually exists yet. Instead, maxver should be restricted to the current version (the app.extensions.version of the latest nightly; admins must keep this up-to-date), but registered users who know how to work around it should be allowed to increase the maxver for any addon (up to the current version). -- Greg K Nicholson 2005-06-03
Agreed. MaxVer should be limited to latest nightly's string. --CTho 19:17, 13 Jun 2005 (PDT)

My Addons

  • List of all your addons columns (sortable) are:
    • Name
    • Downloads
    • Rating
    • Version (latest)
    • Date created
    • Comments
    • # of Screenshots
    • # of Forum Posts
  • All actions can be executed from this page (see below... Edit addon details, View comments, etc.)
  • Alternatively, clicking on an Addon takes the user into "View Addon profile"

View Addon profile

  • Provide item overview, show a mirror image of public profile with edit links to:
    • Edit details
    • View/Edit comments
    • Edit Versions
    • Add a new Version
    • Screenshots
    • Forum discussions

Edit Addon details

  • Name
  • Authors
  • Homepage
  • Description
  • Forum / Support?

View Addon comments

Flag comment for review (give reason)
  • Flags comment for review
  • While under review it is no longer public
  • Developer must provide a reason why it was flagged
Reply to a comment
  • Developer may issue replies in a threaded fashion
Edit/delete a Reply
  • Any content created by the Developer may be edited or destroyed, it belongs to them
  • They cannot edit user comments, however

Add a new version

  1. Choose existing extension
  2. Read RDF and compare to current information
  3. Keep existing or overwrite with new?
  4. Require changelog (bbcode)
  5. Applications / compatibility
  6. OS
Should pretty much be the same as the regular Add screen. -alanjstr 2005-06-01 14:30 EST

Edit Version info

  • Target application min/max update
  • Changelog update
  • OS update

Screenshots

  • Show thumbnails plus captions
  • Clicking on a screenshot lets you edit the caption
Clicking on the screenshot should expand the screenshot to fullsize. Many screenshot thumbnails may look very similar. Instead, the text maybe should be a link to edit the caption, or if no caption exists "Click here to insert caption" may be appropriate --Blind487 16:40, 30 May 2005 (PDT)
Add new Screenshot
  • Upload image file
  • Validate size and dimensions
  • Make this your highlight image?
  • Caption (optional)
Remove Screenshot
  • Delete screenshot
  • Cannot delete highlight image
Make a Screenshot the highlight
  • Link next to the thumbnails that sets the "highlight" flag -- pretty easy

Forum discussions

  • Announcements / Stickies
  • Most active
  • Newest
  • Where will this come from? RSS? Direct DB conn?

Reviewers

Reviewer Use-Case Diagram

Approval Queue

  • List of submitted addons
  • Sortable columns
    • Title
    • Author
    • Date
    • Install / Download Link
    • # Previews
    • Date Submitted
    • Priority
    • # Reviews
    • Apps
  • Actions
    • View / Edit
    • Add a review
    • Approve / Reject
    • Email author

Addon Reviews

  • List of submitted reviews for a given addon
  • Sortable columns (something to think about)
    • OS
    • App
    • Install
    • Uninstall
    • App Works?
    • Clean Profile?
    • Visual Errors?
    • Theme Complete?
    • Previews?
  • Actions
    • Email Author
    • Add a Review
    • Edit Addon versions (compatibility, addon details)
    • View Previews

Email Author =

  • Send email to author - can be done from main list

Install or Download =

  • Must be able to install or download an addon, regardless of application.

Add a Review

  • Fill in addon checklist...
  • Items to check?

Edit Addon Versions

  • Adjust compatibility and app maps.

Approve or Deny

  • Deny requires a reason.

View Previews

  • Open in new window, next/prev/close window.

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.

Systems

  • Work with client developers to determine improved interface for addon installations and updates.
  • The way it currently works is acceptable. When we decide on a new interface / API for how to handle addon updating, we can just increment the updater version.

Database Structure

v1.0 Schema

Thanks to Colin for helping make the v1.0 diagram.

Problems

  • Lacks proper normalization
  • Incorrect typing
  • Non-optimal indexing
  • Non-optimal version comparisons
  • Inconsistent nomenclature
  • Others... ?

v2.0 Schema

The first draft of the v2.0 schema was drafted at midnight, 05/18.

It was made with GraphViz; 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 --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

INSTALL
README
dev
    apps.php
    appadd.php
    appedit.php
    appdelete.php

    comments.php
    commentedit.php
    commentdelete.php

    items.php
    itemadd.php
    itemedit.php
    itemhistory.php

    users.php
    useradd.php
    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
Is .php the proper extension for screen.css.php and *.tpl.php? -alanjstr 2005-06-01 14:30 EST

Expected Behavior (client-side)

Extensions

  • If a newer version is available, display update information.
  • If there is information on the current version, display information so client can update extension metadata.
  • Cases where there is no output (expected error code):
    • Bad inputs (1)
    • Failed query or no DB connection (2)
    • No results (3)
    • Client extension version is greater than anything in UMO database (4)
What about "Client extention version file size does not match reported size?" --Blind487 16:51, 30 May 2005 (PDT)
Retrieved from "https://wiki.allizom.org/index.php?title=Update:Archive/2.0/Developers&oldid=8462"