217554 - Develop a query layer in C++ to speed up the actions JS performs now.

Status: RESOLVED INVALID

(Calendar :: General, defect)

Description

[Mike Young]

Currently several tasks in the calendar are painfully slow due to the fact that
they are performed in JavaScript. We need to move these tasks out of JS and into
a component that is close to the Container. A "Query Layer" in C++ will do this
very nicely.

Comment 1

[Mike Young]

Attachment: Container Query Interface

Its been a while, but here's our proposed interface for the Query Layer

Ideally, we want to take the implementations of these fuctions out of JS and
move them to C++ for speed reasons. We will keep much of the JS infrastructure,
so the UI won't have to change, but instead of running loops through all the
calendars in  JavaScript, we'll be able to do it in C++ with easier access to
the container's objects.

Comments are welcome and sought.

Comment 2

[Justin Wood (:Callek)]

My only concern with this, will it break the xpi interface for calendar, which
is how many non developers get calendar for mozilla...since they download the
"official" builds, and then go to the calendar page and install the xpi.

If it does (not too familiar with XUL/XBL yet) I would say keep the current
functions, as is...and THEN add a call to your C++ code (which would be compiled
if enable calendar is set, or when calendar is made default, disabled when
disable calendar is set).

where the JS functions called with "try" to call your code, and if failed, will
opt to the JS code...though not sure if "tries" can be nested...would need to be
for that support.

Comment 3

[Michiel van Leeuwen (email: mvl+moz@)]

How does this break the xpi? The query interface + implementation would be in
the xpi. Just like libxpical is in the xpi.

Comment 4

[Justin Wood (:Callek)]

heh I added that comment before I fully realized that iCal library compiles with
calendar and is in the xpi (read: I was dumb)

Comment 5

[Mike Young]

PSU is no longer funding students to work on mozilla :-(

The bugs we were working on (with the exception of bug 188660 are now irrelevant
with the massive backend changes that were made to the calendar.

Resolving.