[Cosmo-dev] Re: [Design] Design] [Cosmo] Login-related workflows
mde at osafoundation.org
Wed Nov 15 12:03:41 PST 2006
See below ...
Bobby Rullo wrote:
> Your XDate stuff may be fine, but I think that there's little point to
> rewriting or replacing the existing CosmoDate code when:
> 1) Most of the API is already compatible with the build in JS Date
> 2) CosmoDate was designed with the intention of popping in a better
> timezone system when the time became ripe - now is that time, the hooks
> are in place and it will be easy to do
> 3) The UI relies on CosmoDate already.
> If there's any methods or functionality that you feel are missing from
> CosmoDate that you need to add, by all means do so, but I don't advocate
> pulling out the CosmoDate and replacing it.
Sounds good. There's actually very little code overlap between the
current XDate and current CosmoDate beyond the getter methods. It's
mostly just stuff that's missing.
In fact, CosmoDate is mostly a bag of attributes (with getters) at this
point -- and a few methods, some of which just pass off to our
add/diff/strftime, some of which are convenience (after/before), and
some which we might not need if we could instantiate just like a normal
JS Date (e.g., updateFromUTC)
How we get there is way less important to me than where we end up. I
just want to minimize work, and maximize benefit to us. So here are a
few of the things banging around in my head about this:
1. We want to get our timezone-capable Date replacement into Dojo, so
others can use it, we aren't maintaining it by ourselves, and we get
bugfix support from the community (it's also good press for OSAF).
3. Dojo is highly unlikely to implement something called 'CosmoDate.' I
don't think anyone there is religious about the name, but 'Cosmo' ... ? :)
2. Adding in real timezone support is already a fairly large project,
and it would be nice only to have to make the large change to all the
code one time, rather than once now, and once after our code moves into
Again, I don't care what we call this date thingie -- the only reason I
advocate a name change now is that it saves me work in the UI code later
down the road. We're already jacking up CosmoDate, so now would be a
good time for a large change like this.
As for the functionality, there's very little overlap, so it's just
filling in the gaps. All those getter methods are exactly the same. My
suspicion is too that some of the Cosmo-specific methods will involve
some rewriting for real timezone support anyway (e.g.,
Basically, I just want to be able to use a timezone-aware date just like
methods, and fixing the constructor method so that it doesn't just
blindly set property values from the params passed in.
(Also it would sure be nice just to call dojo.date.add and pass it one
of these dates instead of having a special static method call directly
on our date object. And a pony.)
I also really like the idea of having a separate Date-only data-type,
but some folks might think it's not necessary. It just seems to give
server-side guys more options, and doesn't really add that much
More information about the cosmo-dev