MozillaWiki - User contributions [en]

SeaMonkey:Project Organization

2006-10-18T21:11:04Z

Nikai: /* SeaMonkey Council */ sp

{{SeaMonkey-Resources}}

This page describes the structure of the SeaMonkey project. For now, only drivers are listed, but it will be updated with the structure for the rest of the project as soon as we have figured it out.

==SeaMonkey Council==

The SeaMonkey Council is the team responsible for project and release management, and can be contacted via the email address [mailto:seamonkey-council@mozilla.org seamonkey-council@mozilla.org].

===Christian Biesinger (biesi)===
Christian has been working on Mozilla for a few years; he mostly works in Gecko code, but also does UI patches occasionally. He wrote the image decoders for BMP and XBM files. He also wrote a [http://wiki.mozilla.org/wiki/User:Biesi Plan to make SeaMonkey use the "new toolkit"].

===Robert Kaiser (KaiRo)===
KaiRo is the head of MLP staff (Mozilla Localization Project) and has worked on localizing SeaMonkey since late 1999 (M11/M12). He's also doing the EarlyBlue and LCARStrek themes and has done some work on making some parts of the product localizeable and themable. See also http://wiki.mozilla.org/wiki/User:KaiRo and http://mozilla.kairo.at/

===Ian Neal (IanN)===
Ian does work on XUL/JS stuff (mainly UI but also some backend) with a little bit of simple C++ stuff thrown in. He peer reviews on help and has been actively involved in Seamonkey development for about two years.

===Neil Rashbrook (Neil)===
Neil is the "module owner" of XPFE (most of the SeaMonkey-specific code), and a super-reviewer focussed on XPFE and MailNews. He has been very involved in all SeaMonkey related development for years.

===Christopher Thomas (CTho)===
Chris has been a Mozilla user for about 3 years, and started as a developer about a year and a half ago. His interests have been mostly in the Mozilla frontend. He is experienced with JS and C++. While he has not been working with Mozilla as long as the other drivers, he has been very active in organizing the new SeaMonkey group, and putting together various proposals.

==Project Area Owners and Peers==

The SeaMonkey Project can be divided into several areas, which are listed on our [http://www.mozilla.org/projects/seamonkey/project-areas.html project areas list]. Each of those areas should have an owner and possibly several peers (people who know the code well enough to give reviews there), who together care about that area.
The sum of those areas build a strong group of developers, who can move the SeaMonkey project forward.

[[category:SeaMonkey|p]]

Language agnostic event handling

2006-03-08T12:56:04Z

Nikai: sp

=Language Agnostic Event Handling=

This document is a place to dissect the current event handling mechanism and make it language agnostic.

This currently contains notes randomly pulled from [[Memory Management for nsIScriptContext]], and will be fleshed out soon.

===Compile the script handler===

Currently nsJSContext::CompileEventHandler does take the "event target" as a param - however, this is only used to setup principals, and does not otherwise "bind" the compiled function to the event target. (Note: Brendan and I agreed that this param could be dropped from CompileEventHandler() to reinforce this lack of "binding", and the principals thing is apparently no longer necessary. Note however that CompileScript *does* still take an nsIPrincipal param - is that still necessary?)

Due to this lack of binding, the "void *" returned by this function is identical to CompileScript above - the callers must ensure these unbound handlers are rooted if they hold on to them - there is no "implied reference" setup.

===Bind the handler===

This process binds the compiled event handler to a specific target. In effect, this takes a copy of the compiled handler and "magically" associates it with the event target (see below). After this process, the original compiled event handler is thrown away (and as the caller did not GCRoot the original, it will be disposed of by GC). Critically however, this binding process has created an "implied reference" to the event target - once bound, other assumptions are then made that the event target will not be destroyed.

===Call the bound handler===

The "void *" passed to CallEventHandler is not the "void *" previously returned directly from CompileEventHandler. Instead, the "magic" association above is reversed, fetching a function object, by name, from the JS wrapper around the original event target. Thus, currently the "void *" used is not supplied directly by nsIScriptContext, so the interface must be abstracted so it is.

==Notes:==
Theoretically, the above setup should mean that an event handler for a specific object only requires the original event target and event name to fire the event. The "magic" association would ensure that when querying for the event name, the previously cloned function object will be located. However, even though this should be possible, it does not happen for XUL, which stores its XPCWrappedNative pointer in its nsJSEventListener. Thus, XUL is now storing a weak reference to a different interface, not the event itself, in the assumption neither will go away. XBL appears to store the original target.

The nsJSEventListener only keeps a borrowed reference to the target. Even though currently an XPCWrappedNative is stored in place of the original event, it is still a borrowed reference. This borrowed reference itself relies on the "implied reference" model below - without that implied reference, the weak reference to the object in nsJSEventListener would fail. Note also that all of this "WrapNative" work happens *outside* nsIScriptContext, so we need to work out how to abstract it behind that interface.

==The "implied reference"==

The above relies on an "implied reference" existing on the event target, via the "long-lived XPCWrappedNative" concept supported by XPConnect. This mechanism is used by XPConnect tn ensure the same JS wrapper is always returned for a given DOM nsISupports. While this model makes sense and all other languages would be encouraged to follow something similar, the nsIScriptContext model should not make any such implementation assumptions. Other languages may be able to perform the same magic using a different technique than XPConnect uses, and any "implied references" may not be true. For example, other languages may choose to implement this with weak references to make their own ownership model simpler.

== Event Handling Options ==

There are 2 options here - one relies on reusing the mechanism above for unbound functions, and the other relies on explicit xpcom strong references.

NOTE: I'm still looking at the existing code trying to come up with a concrete proposal.

====Have BindCompiledEventHandler() return an out void **====

This may be the simplest - this would return a new void **, which must be passed to CallEventHandler(). This new void * is subject to the same rules as unbound handlers, and must be individually unlocked.

Language implementations are then free to have this "void *" indirectly hold a strong reference to the event target (or in the case of JS, need only ensure that the wrapper persists)

====Formal binding objects====

The process of binding to an event handler can return a new nsISupports object. (As mentioned above, XUL already stores a different nsISupports pointer from the original event target - it just assumes that pointer has the same lifetime). A strong reference to this returned object must be kept and the "binding" is only guaranteed to remain alive as long as the object. Once the binding has been dropped, a new Binding can be created, but it is not guaranteed the returned nsISupports will be the same.

As this is a strong reference, it will be necessary to ensure these references are manually dropped. This means that all nsJSEventListener objects must be explicitly dropped. I believe this already happens now.

Memory Management for nsIScriptContext

2006-03-08T12:51:44Z

Nikai: sp

=Script Object Lifetime Management=

The problem:

Certain nsIScriptContext methods return a |void *| tied to the specific language. For example, |CompileEventHandler| returns a "function" object which is held by the caller and later passed to |CallEventHandler|. The lifetime of these returned |void *| objects must be managed.

At the high-level, it has been agreed that new methods |DropScriptObject| and |HoldScriptObject| will be added to certain language-specific interfaces. The affected |nsIScriptContext| methods will return a 'held' object; the caller must call |DropScriptObject| when it no longer needs to store it. |HoldScriptObject| is provided so that copies of the objects can be made. This is identical to a reference counting scheme, but named to avoid confusion with XPCOMs reference counting.

We need to turn this into an actual implementation, with the following restrictions:

* We want to avoid additional memory allocation or virtual method calls. The only overhead the Drop/Hold scheme requires is one additional virtual-method call for the memory management function itself.

* We can not have the memory management functions exclusively on nsIScriptContext. There is code that currently stores a |void *| script object, but has no nsIScriptContext available. One example is nsJSEventListener, which stores the |void *|, but has the |nsIScriptContext| provided as part of invoking the event. nsJSEventListener would not want to store an nsIScriptContext just to free the script object. Another example is the XUL cache which will be extended to cache all languages, but will not want to store an nsIScriptContext just to handle cache shutdown.

* Linkage issues mean that "helper functions" are unsuitable for use here. As the DOM implementation and each language implementation are individual components, public static functions are not globally reachable. Either xpcom interfaces or fully inline C++ classes can be used to assist with these tasks.

== Implementation idea #1 ==

Add DropScriptObect/HoldScriptObject to nsILanguageRuntime (a new class - a 'singleton' for each language - it creates nsIScriptContext objects amongst other things). Code then only needs an integer language ID to be able to free the script object.

A downside of this approach is that all memory management functions take an extra penalty. Each function involves:
* Fetching the nsDOMScriptObjectFactory service.
* Fetching the nsILanguageRuntime from the nsDOMScriptObjectFactory passing the int langID.
* Calling the nsILanguageRuntime::Drop/HoldScriptObject function.

This problem could be solved by either:
* Duplicating these functions on nsIScriptContext, so code that does have a context available can do so without the additional overhead.
* Having performance critical code keep a reference to the nsILanguageRuntime.

Even still, a key problem to this approach remains its fragility. By explicitly requiring manual Drop/Hold calls, there is a lot of scope for programmer error in the face of error conditions (ie, early returns) to cause difficult to track leaks. The inevitability of such errors is evidenced by nsCOMPtr and various other tricks already in the code base.

== Implementation idea #2 ==

This implementation builds on #1 as its core framework, and attempts to add a "helper class" (nsScriptObjectHolder) to automate the management of these objects. All nsIScriptContext methods that return a "new" script object now take a reference to one of these objects.

The public prototype for this class is:

class nsScriptObjectHolder {
public:
nsScriptObjectHolder();
nsScriptObjectHolder(PRUint32 aLangID, void *aObject);
nsScriptObjectHolder(const nsScriptObjectHolder& other);
~nsScriptObjectHolder();
nsScriptObjectHolder &operator=(const nsScriptObjectHolder &other);
PRBool operator!() const;
operator void *() const;
nsresult set(PRUint32 langID, void *object);
nsresult set(void *object);
nsresult set(const nsScriptObjectHolder &other);
nsresult clear();
PRUint32 mLangID;
};

the nsIScriptContext methods changed are CompileScript, CompileEventHandler, GetBoundEventHandler, CompileFunction and Deserialize, with all changes similar to:

virtual nsresult GetBoundEventHandler(nsISupports* aTarget, void *aScope,
nsIAtom* aName,
- void** aHandler) = 0;
+ nsScriptObjectHolder &aHandler) = 0;

Code calling these methods changes from:
void *handler = nsnull;
rv = context->GetBoundEventHandler(..., &handler);
if (handler)
context->CallEventHandler(..., handler)

to:

nsScriptObjectHolder handler;
rv = context->GetBoundEventHandler(..., handler);
if (handler)
context->CallEventHandler(..., handler)

The use of "operator void *" and "operator !" means that much existing code that uses |void *| can remain unchanged once the variable has changed to nsScriptObjectHolder. For example, an nsScriptObjectHolder can be passed to nsIScriptContext::CallEventHandler, even though the prototype remains |void *|.

=== Problems ===

* The nsScriptObjectHolder class must have a fully inline implementation. Any attempt to use methods defined in gklayout.dll mean the class can not be used by external languages (such as Python).

* This does not lend itself to allowing DropScriptObject/HoldScriptObject on both nsIScriptContext and nsILanguageRuntime. As not all callers can use nsIScriptContext, it must be nsILanguageRuntime. This means each memory management function is slightly expensive, as detailed above.

== Implementation idea #3 ==

Use a real XPCOM interface. Something like:

interface nsIScriptObjectHolder : public nsISupports
{
virtual void *GetScriptObject();
}

and all nsIScriptContext methods return one of these interfaces instead of a |void *|. The memory management is then implicitly tied up in the lifetime of the interface itself.

=== Problems ===
* Fetching the |void *| language object becomes a virtual method.
* Each call requires a new allocation for the interface.

== Notes ==

Implementation idea #2 has been implemented and works well. However, concerns exist regarding the performance overhead in terms of speed and bloat.

Calendar:Deprecated:Feature Requirements/Roadmap Review

2005-01-28T13:37:07Z

Nikai: sp

The current [http://www.mozilla.org/projects/calendar/requirements.html Calendar Feature Requirements] and [http://www.mozilla.org/projects/calendar/roadmap.html Roadmap] documents on the website seem to be a bit out of date.

I've copied them here so we can edit them

-lilmatt

Calendar Feature Requirements (revision 2.0)

This document covers all the requirements, which we want to accomplish in the coming months and years. Please note, that this is not a roadmap. Since we currently lack active developers we have no timeframe for all the uncompleted features.

A lot of the functionalities have already been completed. These are shown as striked-through. The rest is either being worked on or needs developer attention. If you want to contribute to the project these tasks are your best way to get into it. Please see the FAQ and the developer guide for information on how to contribute to the project.
Table of Contents

1. Appearance & Performance
2. Alarms
3. Associating
4. Categories
5. Exporting
6. Events
7. Importing
8. Integration
9. Invitations
10. Multiple People
11. Printing
12. Remote Access
13. Search
14. Settings
15. Synchronization
16. To Do List
17. Views
18. Standalone Build (Sunbird)

1. Appearance & Performance

* New theme using new toolkit and Winstripe-style icons.
* Review of calendar performance especially with large files.
* Support for archiving old events and tasks.

2. Alarms - tracker bug

* The format of the alarm will be to open up a dialog window. The user will be able to dismiss the alarm, or snooze it for X number of minutes, days or hours, where X is an integer.
* Alarms give a snooze function (remind me in X minutes, snooze past event start, remember status when Calendar is turned off).
* Snoozing alarms should persist. If you snooze an alarm, and then shut Calendar down, it should remember that the alarm was snoozed.
* Alarms that have passed when PC has been off will go off on Calendar start-up.
* Alarms can be turned off globally.
* Alarms can be set X minutes, days or weeks before the event in the form of pop-up or email.
* The user should be able to snooze events for a certain time, and for a certain amount of time before the event. [Remind me again [___] (mins / hrs / days) (from now / before event)] PARTIALLY COMPLETE (just regular snooze)
* The user should be able to see all the alarms that have not gone off.
* The user should be able to have multiple alarms for the same event. You could have one to remind you to prepare for the event, and another that the event is occurring.
* Alarms must go off when calendar is not running.
* Email that is sent out needs to be configurable (e.g include notes from event, "%user wrote:")

3. Associating - tracker bug

* Events can have locations assigned to them.
* Events can have notes or bookmarks attached to them.
* Calendar events can have files attached to them.
* Events can have attendees (contacts or mailing lists) associated to them (after Server support).

4. Categories - tracker bug

* Categories should be user-definable (add/edit/delete functions).
* Field to associate with any event (meeting, Address, Call, etc.) to a category. There could be some default categories (e.g., Family, Friends, Work, Clients, Subcontractor, Restaurants, Computer)
* Events can be filtered based on categories.
* Events can be associated with multiple categories.

5. Exporting - tracker bug

* Ability to export to another ICS file on file system or WebDAV folder.
* Ability to export only selected events.
* Export to HTML (pretty much the same as Print).

6. Events - tracker bug

* Events can be added, edited or deleted and (if applicable) re-published via WebDAV.
* Events can be all-day events or even span multiple days.
* Events can be repeated every X days, weeks, months or years as well as on every X-day or Yth of each month.
* Repeating events can have exceptions applied to them.

6.1. Add / Edit / Delete Events

* The user must be able to add/edit/delete an event regardless of its location (local or remote) if they have enough permissions. PARTIALLY COMPLETE (no remote, requires calendar server)

6.2. Repeating events

* Events can repeat every X day, week, month or year.
* Events can repeat every week on certain days of the week, eg. Monday and Tuesday of every week.
* Events can repeat every day of a certain month and a certain date of every month. eg. 19th of every month, or 3rd Monday of every month.
* Users should be able to add exceptions to repeating events.

7. Importing - tracker bug

* Import MS Outlook and other popular calendar data.
* Import other Mozilla calendar data (see 5 - Exporting).

8. Integration - tracker bug

* Receiving an email invitation should bring the calendar up to prompt to import file.
* Finish integration with Thunderbird as an extension.
* Accept Outlook invitations.

9. Invitations - tracker bug

* You should be able to email invitations to people to inform them and invite them to the event. (using WebDAV only)
* Guests will be alerted when the event is modified or deleted (Pop-up to offer re-notification). (needs Calendar Server support, see 10. Multiple People)
* Responses to invitations that come via email will prompt to import into the calendar.

10. Multiple People - tracker bug

* The calendar should be able to show other people's calendars, and let you edit events for other people with the proper permissions. (Completed using WebDAV only)
*

Ability to store multiple calendars on a calendar server, options for the calendar software include:
o Sun's ONE calendar server
o phpGroupWare
o eGroupWare
o OpenGroupWare.org (OSS version of Skylix)
o Exchange4Linux (formerly Bill's WorkGroup Server)

11. Printing - tracker bug

* Printing of day, week, month view with or without his calendar events as displayed on screen.
* Printing support for tasks together with categories, percentage complete and due dates.
* Print list of events with start and end dates, categories and locations.
* Print only what is defined by the drop down "View" menu or the current search.
* Option to leave out white space, i.e. Only print when I'm busy.

12. Remote Access - tracker bug

* Users can access and subscribe to remote calendar files, re-publishing them with permission. (using WebDAV only)

13. Search - tracker bug

For saved searches, see the 17. Views which enables the "View" drop down menu

* The user should be able to do a simple (quick) search for events.
* Search facility from toolbar allowing quick search based on title, location and description (notes).
* The user should not have to press a search button, it should search automatically after a certain period of time has elapsed since typing.
* The user should be able to do an advanced search for events (design done).
* Pop-up window to enable advanced search by selection of what fields to search in (including time and date). [Design already done]

14. Settings - tracker bug

* Options to configure start of week, hours in day and alarm defaults (as well as others).
* Option to pick colours for each calendar.
* You should be able to see the week number.
* Ability to set text colour for calendars as well as highlight colour.
* Setting dialog needs updating to new style (see Firefox and Thunderbird as examples).
* Change all preferences to be stored under MozillaCalendar rather than below Mail or Thunderbird.

15. Synchronization - tracker bug

* Sync data with mobile devices:
o Palm Pilot (custom format)
o Pocket PC (runs Outlook PocketPC version)
o Nokia mobile phones (format?)
o Sony Ericsson mobile phones (format?)
o Apple iPod (uses ics) [DIGITALgimpus started work]

16. To Do List - tracker bug

* Sidebar for displaying to do task list.
* Alarms for to do tasks.
* To do list for simple tasks.
* To do tasks should be searchable (see 13 - Search)
* To do tasks should appear in main view, if global option is set.
* To do list should be viewable by category, due date and percentage completed.

17. Views - tracker bug

* Day, week, multi-week and month views, supporting resizing and multiple events at one time.
* List of all events, configured by View or Search options.
* The month view should show the trailing/following days of the previous/next month, not just the days of the current month.
* Show a work week view which shows a user specified amount of days (some people work Mon - Fri, others work Tue - Sat).
* In-line editing for events in both list view and calendar view.
* Drop down "View" menu should be configurable (as in Thunderbird/Mail) and provide Save option.

17.1. Day View / Week View

* When switching to day view, it should scroll until a certain time is at the top (like 8 AM).
* Events that occur at the same time as each other should still be shown (ie. be squished side by side).
* You should be able to double click on an hour and then have the new event dialog pop up for that time.
* Day view - Configurable hours in day.
* Week view - Monday to Friday support for Week view.
* You should be able to delay double click on an hour and then have an inline edit box pop up for easy and quick calendar adding.

17.2. Month View

* It should be able to be resized to any width and height.

17.3. MultiWeek View

* Multiweek view should display a grid of days (similar to month view).
* Multiweek view should display weeks relative to current week (not current month).
* Multiweek view should display T weeks total, where T is a user settable preference.
* Multiweek view should display P previous weeks, where P is a user settable preference.

18. Standalone Build (Sunbird)

* Make standalone build compile from the mozilla trunk.
* Make standalone build really standalone (resolve the dependency on building it on top of Mozilla Firefox.
* Complete the artwork/theme in standalone build.
* Resolve integration issues (mail and browser integration)

Mozilla Calendar Roadmap

This page documents our goals and feature requirements for our upcoming releases. Since we currently lack active developers, no timeframe for upcoming releases can be given.

For a more thorough overview of our completed and uncomplete features, please visit our Feature Requirements page.
Calendar 0.9 - "Almost there..."

Items to resolve:

* 1. Appearance & Performance - New theme; Ability to archive old events and tasks.
* 3. Associating - Events can have files attached to them.
* 4. Categories - Events can have multiple categories.
* 5. Exporting - Export to HTML
* 8. Integration - Complete integration with Thunderbird.
* 11. Printing - Support for printing To do tasks; Support for printing list of events.
* 14. Settings - Option to set text colour for calendars; New independent preference folder.
* 16. To do - Tasks to appear in main view (if option set); Filter views by category, date due...

Calendar 1.0 - "Finally!"

Items to resolve:

* 1. Appearance & Performance - Performance increase especially when dealing with large files.
* 2. Alarms - Configurable email; Alarms triggered when Thunderbird/Mail only is running.
* 8. Integration - Accept Outlook invitations.
* 11. Printing - Option to leave out white-space; Print only results from search or "View" filter.
* 13. Search - Pop-up window for advanced search.
* 14. Settings - Change settings dialog to new style and theme.
* 16. To do - Search facility.
* 17. Views Drop down "View" filter menu should be configurable.

Plans for the time after 1.0

We will branch into 1.0 and 2.0 trees which are developed concurrently

Branch 1.0 will probably follow this release plan:
1.1: Bug Fixes
1.2 - 1.4: Beta Releases of Stand alone build, Sunbird
1.5 - 1.1: Build re-release as stand alone build, Sunbird

Branch 2.0 will probably follow this release plan:
1.6 - 1.7: Alpha Releases of next generation release
1.8 - 1.9: Beta Releases of next generation release
2.0: Release of next generation calendar, both as extension and stand-alone build
Calendar 2.0

Items to resolve before a 2.0 release:

* 9. Invitations - Guests will be alerted when events changed; responses automatically imported.
* 10. Multiple People - Support for various calendar servers.
* 15. Synchronization - Support for sync with mobile devices.
* 17. Views - In-line editing for events in both list view and calendar view.
* 18. Standalone Build - Full support; as feature complete and as stable as Calendar

Calendar:Lightning

2005-01-28T13:16:38Z

Nikai: /* Lightning Q & A */ sp

= Lightning =
'''Lightning''' is the working project name for an extension to tightly integrate calendar functionality (scheduling, tasks, etc.) into [[Thunderbird:Home Page|Thunderbird]].

This page was last updated on January 24th, incorporating edits to this page and the discussion area (though not by any means completely).

= Other Lightning Pages =
* [[Calendar:Lightning:Search]]
* [[Calendar:Lightning:Invitations and inbox]]
* [[Calendar:Lightning:Calendar views]]
* [[Calendar:Lightning:Event view]]
* [[Calendar:Lightning:Task management]]
''(some of these don't exist yet!)''

= Lightning Q & A =
A quick question and answer, to get us started:

'''Q.''' ''When will Lightning be available?'' 
'''A.''' As Lightning is still early in the design and prototyping stage, there is no firm availability date yet. The developers of Lightning are currently targeting a first general-user release for the middle of 2005.

'''Q.''' ''Will this be Mozilla Lightning™? Is this an official Mozilla Foundation product?'' 
'''A.''' "Lightning" is simply a project code name to keep from having to type or say "Thunderbird extension for tightly-integrated calendar functionality" all the time. You can think of it as analogous to "Seamonkey", which was never used as an official product name. The Mozilla Foundation has not yet announced any plans to add Lightning to its set of supported products under any name; indeed, such an announcement would be premature, as the exact composition of Lightning is still very much under discussion.

'''Q.''' ''So what about the existing Mozilla Calendar extension for Thunderbird? Does Lightning replace that?'' 
'''A.''' The Mozilla Calendar extension for Thunderbird is a separate project and codebase, though all Mozilla Calendar projects (the extensions, Sunbird, Lightning) will share the core calendar components and protocols. While the Mozilla Calendar extension for Thunderbird acts essentially as an alternate launcher for the Sunbird application window, Lightning is designed to integrate into the main Thunderbird UI and user interaction model as tightly as possible.

'''Q.''' ''Is Lightning meant as a competitor to Outlook?'' 
'''A.''' With Lightning, Mozilla Thunderbird will have a set of user features that is much more competitive with Outlook, especially in enterprise usage. The primary goal of Lightning is to provide a pleasant and productive user experience for both email and calendaring tasks, largely independent of specific competitors' product plans. If the result of the Lightning project is an acceleration of users' migration from Outlook to Thunderbird, though, very few tears will be shed.

'''Q.''' ''Seriously, though, if you're not aiming at Outlook users, what are you doing?'' 
'''A.''' Given Outlook's immense share of the email and calendaring market, it would be foolish to ignore its capabilities and characteristics, from both user and administrator perspectives. While Lightning will certainly incorporate concepts from Outlook -- as from other email/calendar applications, such as Evolution, Remail and Chandler -- it is not designed to be simply an "Outlook knock-off". Just as Thunderbird improved the email experience beyond what is provided by Outlook and Outlook Express, Lightning is designed to improve the calendaring experience for Outlook converts and newcomers to calendaring applications alike.

'''Q.''' ''Will Lightning have support for <whatever> servers?'' 
'''A.''' Lightning will support the full range of calendar mechanisms and protocols supported by the Mozilla Calendar infrastructure, just as with modern (post-0.2) Sunbird. More information on protocol support can be found on the [[Calendar:Protocol/Storage Providers]] page.

'''Q.''' ''With what devices will Lightning be able to sync?'' 
'''A.''' As with protocol/server support, Lightning will inherit all its sync support from the Mozilla Calendar core. More information on the state and goals of the sync support in Mozilla Calendar can be found on the [[Calendar:Device Sync]] page.

'''Q.''' ''Will Lightning have re-mappable shortcut keys/drag-and-drop UI configuration/other app-level features?'' 
'''A.''' Lightning strives to be as well-integrated into the Thunderbird application as is possible. This means supporting the same levels of configuration and user interaction as its host Thunderbird, so the answer to these questions is usually "please ask the Thunderbird guys".

'''Q.''' ''Where can I learn more? (Or: I have a Great Idea!)'' 
'''A.''' This wiki section will collect more documents about Lightning. Also, the mozilla.calendar newsgroup is a good place to read about Lightning, and ask questions. '''Please use the discussion tab above''' (or in another lightning-related entry!) to add comments and additional questions. I'll come back through here as frequently as time permits and incorporate them appropriately.