On 9/23/13 2:34 PM, Benjamin Smedberg wrote:
On 9/20/2013 3:12 PM, Philipp Kewisch wrote:
We are not quite ready to get rid of the libical backend right now, so
removing these functions without replacement will cause some
complications for Lightning.
Not knowing this code well, it seems that this code takes a double and
converts it to a JS date object with some timezone conversion. It seems
to me that you could write this code entirely in JS and just pass around
the integer or double values using IDL, to avoid the JSAPI usage
altogether. That might involve always replacing calDateTime with a
JS-implemented wrapper, but that's the kind of technique that we need to
be encouraging in general.
Is that technique a usable workaround for raw JSAPI usage?
The code really just takes a PRTime type value and creates a javascript
date object out of it. If its a local timezone (floating), then use the
fields directly, otherwise create a jsdate from the PRTime.
Initially it seems it would be easy to replace calDateTime with a JS
component and I had started to do this, but unfortunately calDateTime is
instanciated directly (via constructor, not via xpcom) in a few
locations in our C code, so replacing only calDateTime with a JS
implementation wouldn't really work out well. Replacing all the other
components comes close to using the new backend, which is not ready yet.
If there would be some secret backdoor to continue using JSAPI that
would give us a little bit longer before we replace the whole backend, I
could live with this happening.
Philipp
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
