Update:Archive/1.0/Overall Plan

« Back to Archive | Update: Main

	THIS PAGE MAY BE OUTDATED
	This article is in parts, or in its entirety, outdated. Hence, the information presented on this page may be incorrect, and should be treated with due caution until this flag has been lifted. Help by editing the article, or discuss its contents on the talk page.

Introduction

The following page will give an overview of what the overall plans are for development and deployment of the UMO service.

Getting our Bearings

We have an application that we do not know what it does fully. In addition, we do not have a clear idea of key policy issues as well as any documentation on the overall architecture of the UMO service. The first two weeks will be spent assessing the situation so that we know what we have and what it does.

Development

There are two main components to development at this time; getting v1.0 stablized and to a point where we feel comfortable with public consumption and then the re-engineering of the UMO service with v2.0.

Getting to version 1.0

Getting to v1.0 is all about plugging the holes and getting the service re-enabled. We have some short timelines ahead of us that we need to take into account. See the complete v1.0 plan.

Getting to version 2.0

In our discussions on #umo we have talked about a few things in regards to v2.0. The overall opinion is that we should rewrite completely from scratch so as to take advantage of frameworks/tools to scale the application and grow it over time better. See below for a summary of questions regarding UMO v2.0. See the complete v2.0 plan.

What language should we use?

Sticking with PHP seems to make the most sense at this time. We have that skill set (both on the development and systems side) and the alternatives are not particularly attractive. We considered both Perl and Java but decided against both at this time. The existing UMO service is currently scaling quite well with over 3 million unique clients a day across 3 servers.

What tools/frameworks will we use?

This is an ongoing discussion that will hopefully yield the "best tools for the job".

What about 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.

When is X going to happen?

Until we have a clear picture of what we have and where we are going, we won't have a timeline. Right now the goal is to get an assessment completed by 2/1/2005 which will help drive our development efforts moving forward.

Infrastructure/Deployment

In looking at the future, we need to identify what it's going to take to handle the UMO service during peak loads. The community will not judge us on how sexy UMO is or the tools built around it. We believe the community and pundits will be most critical of UMO if it fails to perform during peak usage. If a new security update is released and UMO melts down, that will reflect poorly on the use of Firefox but also the Mozilla Foundation as a whole.

The existing infrastructure will not scale to handle peak loads at this time. Peak loads will occur when new and popular extensions come out and most notably when security updates are released. We need to build a scalable, reliable and secure infrastructure to handle the delivery of the UMO service to end users.

Corey Shields will be tasked with coming up with a plan for this and presenting it to the Mozilla Foundation system administrators. The OSL would be willing to completely manage this service up to the application layer (including upgrades, etc) for the MoFo.