Calendar:Status Meetings:2006-04-013:ircLog

<dmose> let's give another minute or so, and then get going
<dmose> ok, would someone like to volunteer to scribe?
<lilmatt> not it
<dmose> heh
<jminta_> i can do it if you don't require the notes to be up until tomorrow, i can't do it live
<dmose> jminta: sure, a lag on the notes is fine
--> ctalbert_ (chatzilla@moz-2F355DBD.sw.biz.rr.com) has joined #calendar-mtg
<dmose> ok, first a followup on last week's action items
<dmose> i posted a draft of the module owner state of the world; i haven't yet finished the "how we evolve / scale" plan
<dmose> that's at the top of my to-do list
<dmose> mvl's not here, so i'm not sure what the scoop on the camino review process is
<dmose> i sent out mail to hecker and shaver this morning proposing that a moz developer day be held in june
<dmose> so that we'll have a time and place to all get together
<dmose> i'll keep you posted as i hear more
<dmose> shaver's first reaction was that june might be a difficult month
<dmose> finding someone to own getting download numbers (or doing it myself) is still on my list
<dmose> it sounds like noone is going to make the freebusy day in DC in a few weeks
<lilmatt> will that be hard given all the mirrors?
<lilmatt> download numbers ^^^^^^
<dmose> lilmatt: possibly; i assume this problem has already been attacked for firefox, though
<lilmatt> k
<dmose> so we may still be able to get a representative set of numbers, if not complete
<dmose> ok, onto today's items
<dmose> because the "how do we evolve doc" isn't done yet, and because several folks who are likely to care a lot about this aren't here to participate, i'm going to push that item to next week
<dmose> i'll try and get the "how we evolve" doc posted in the next or so, however
<dmose> sunbird 0.3a2 status
<dmose> jminta: you want to take that one?
<jminta_> well, the main problem we've run into seems to be daylight savings stuff
<jminta_> which, i'm *hoping* can be worked around via giving sunbird a tz-picker
<jminta_> given that we've lost mvl for the weekend, and i'll be off from saturday to monday, we're probably not going to be able to release until, at best, next week
<dmose> makes sense
<dmose> so if we're lucky, the picker will land over the next couple of days for baking over the weekend?
<jminta_> yes, although there still could be an issue with previously saved events
<dmose> because they will have the wrong timezone, you mean?
<jminta_> and we'll need to make a decision on how to handle that
<jminta_> yes
<lilmatt> will they have _wrong_ tz or _no_ tz
<jminta_> my fear is that we may need to try to implement a tz-picker for <datetimepicker>
<dmose> no tz == a Zulu time?
<jminta_> lilmatt: wrong-tz is most cases
<dmose> jminta: i suspect we're going to need to do that anyway
<jminta_> 0.3a1 used 'floating' though, so it's really only our nightly users that i think will be in toruble
<dmose> jminta: even iCal has that, and that's as consumer-focused as you can get
<ctalbert_> It might be better to use "floating" for no tz. That maps better than zulu
<jminta_> dmose: right, it's just that that will be substantial work
<dmose> jminta_: you mean you think it will be important to have that for 0.3a2?
<jminta_> dmose: it might
<dmose> ctalbert_: yeah, definitely
<dmose> jminta: why?
<jminta_> because otherwise users are kinda stuck with weird behavior in those events
<dmose> oh, hmm
<dmose> well, i have one or two other possible thoughts, but they can probably wait until after this meeting
<jminta_> yeah, so summary: tz/daylight issues are the main holdup
<dmose> ok, so next item: brainstorming
<dmose> as we're thinking about product design & users that we're designing for, one thing that i think is likely to be helpful
<dmose> is to try and come to some level of agreement on what it is exactly that we're trying to do, at a very level
<dmose> s/very/very high/
<dmose> in particular, why is it interesting for the mozilla project to be involved in calendaring?
<dmose> i spent some time thinking about this, and to me, it seems like one possible way of looking at this is
<dmose> that we want to use the net to make time management and scheduling easier for people
<dmose> i'm curious as to what folks think about that as a summary of a raison d'etre
<dmose> and what other possibilities there are
<jminta_> also note that there really isn't any cross-platform calendaring solution in existence at this stage
<dmose> that kinda depends how you segment
<dmose> i can think of a bunch, but they tend to have caveats
<dmose> eg "meeting maker/notes, but they're proprietary"
<dmose> yahoo/google calendar, but they're web only
<ctalbert_> I think yes, you want to use the net to make time management easier for people, but you also have to realize that there must be an offline solution. Most people who are not programmers are not online very much of the time.  Which is where a thick client app like lightning or sunbird comes in.
<jminta_> i agree with ctalbert_, i'm reluctant to have 'net' feature so prominently in our reason for existence
<dmose> well, when i say "net", i wasn't referring to constant connectedness
<ctalbert_> you meant sharing and such?
<dmose> but, rather, things like the ability to get at your calendar from multiple places, and to interact with other people's calendars, and share your own, and discover events via evdb
<dmose> and publish iCalendar and hCalendar stuff
<lilmatt> however one aspect that holds us (as well as everything mentioned before except mmaker/notes/outlook/corptime) is the lack of freebusy & resource scheduling, so net is important.
<muhjiko> you might want to hook unto googles online calendar, or even get there first choice in calendar applications, just as ff did
<lilmatt> holds us back...
<dmose> muhjiko: yeah, i think it would be constructive to have discussions with them at some point
<dmose> right, so open standards are a big part of what we're trying to use and drive here, i think
<lilmatt> Yes.
<jminta_> do we want to take a page from firefox's book and include "increasing choice"?
<jminta_> or choice/innovation
<dmose> maybe
<dmose> that positions us more as an outlook competitor, however
<dmose> because there's no shortage of choice or innovation in the web-calendaring space
<jminta_> right
<dmose> and while trying to compete with outlook is relevant here, i'm not convinced that that's our primary raison d'etre
<dmose> as far as not being too net-centric, i think that would be a mistake, and here's why
<jminta_> do people feel there is a need that we're filling or that we're more geared towards expanding/innovating?
<dmose> some of each, i think
<dmose> there's clearly a need for good calendaring that works offline
<dmose> there's also clearly a little of interesting stuff going on in this space which takes advantage of the net
<dmose> and makes calendaring and scheduling more compelling
<dmose> this actually ties in with why i think the net should be centric to our mission
<dmose> which is that there are plenty of old-school PIMs and really basic calendars for doing calendar-management-only
<dmose> but the innovation is what is likely to make what we (and other net calendars) do more compelling
<lilmatt> (read: we're not trying to reinvent Palm Desktop)
<dmose> because it has the potential to make things easier for users
<dmose> but this is mostly in the realm of scheduling / sharing
<jminta_> why not talk about 'sharing' more generally, which would include other methods of sharing including export/print/etc?
<dmose> eg freebusy, iMIP, shared calendars
<dmose> web pages with hCalendar embedded
<jminta_> right
<lilmatt> Yes. Currently the scheduling/sharing/freebusy stuff in other non-propietary products is pretty horrid.
<dmose> eVite
<lilmatt> (and in some propietary products even)
<lilmatt> Example: I'
<lilmatt> m not rolling out iCal.app to all my folks because it has basically no _real_ sharing/scheduling functionality
<dmose> well, iCall does at least allow you to propose meetings via iMIP, right?
<ctalbert_> I think that sharing is where it's going to be at. Most of the sharing applications out there .Mac, simdesk etc want you to be a part of their service. What we have a chance to do here is do sharing across all services.
<jminta_> so, not only do we want open standards, but we want people's schedules to be as open and free-flowing as they desire?
<lilmatt> Yes
<lilmatt> ^ to dmose
<lilmatt> ctalbert: Exactly. Don't bind me to your service, be it Exchange, Domino, .Mac, Zimbra, or whatever
<dmose> jminta: for me personally, a lot of this isn't so much about sharing my calendar with folks
<dmose> jminta: as finding and discovering events that are happening locally and making it trivially easy to get them into my calendar app
<jminta_> what is it about?
<jminta_> right
<lilmatt> dmose: My point about iCal.app is that it's really lacking when people are coming from a MeetingMaker/CorporateTime world
<dmose> and in that, i include stuff like parties that people send out evites for
<dmose> lilmatt: yeah, if you're used to be able to look at somebody's freebusy, you're kinda crippled in the current iCal world
<lilmatt> No "Check for conflicts" button 
<jminta_> dmose: i think i agree, basically i meant "people can find my events" = "open" and, "i can get events from anywhere" = "free-flowing"
<dmose> jminta: ok, yeah, does sound like we agree
<jminta_> dmose: but this sounds like it's placing less emphasis on scheduling
<jminta_> and more on search
<jminta_> which i feel like some might disagree with
<dmose> scheduling's a big too
<ctalbert_> And more on publishing
<dmose> witness our attempts to try and get meeting times that all of us can attend
<dmose> it's currently a pathetic email-groping
<dmose> which is really unwieldy
<dmose> s/big/big thing
<dmose> one of the interesting things to me about the internet is that it does allow groups of people to easily collaborate in ways that didn't used to be possible
<lilmatt> cross-organizationally
<dmose> right, exactly like we're doing right now
<dmose> so being able to schedule stuff like online meetings seems huge to me
<jminta_> so, personally, i feel like this is headed back to the imaginary-users, because i feel like the scheduling bit is only interesting to a particular segment
<dmose> oh, absolutely
<dmose> the reason i included this brainstorming in the  agenda
<jminta_> i can bite on the find/retrieve (search) stuff
<lilmatt> Sure I can invite people from work currently in my Oracle Calendar, but why can't I also invite dmose and jminta and KNOW that it's gonna work (unlike current Outlook *-*-*-*-* crap)
<dmose> is that i thought it would help us get a focus on imaginary users and product definition
<dmose> jminta: i'm sure you're right that not all of our users are likely to use scheduling stuff
<dmose> jminta: that said, i think there is room in this space for innovation
<dmose> for example, i think eVite drove a set of users to do online scheduling who never would have wanted to do it before
<jminta_> so i'm just saying, let's make our raison something that covers all the bases
<lilmatt> but there's a whole huge untapped market for a non-Outlook/Exchange scheduling solution
<dmose> jminta: agreed
* jminta_ needs to leave in 5
<dmose> ok
<dmose> so, we've got a good start here.  let's continue this discussion in the newsgroup after the meeting notes / log are posted.
<dmose> next: upcoming priorities
<dmose> given that we're still sorting out our user base & product description, i propose that the thing that it makes the most sense to focus on immediately
<dmose> ie for the next post 0.3a2 release 
<dmose> is dataloss, in particular w.r.t. foreign iCalendar data
<dmose> because this buys us a whole group of people who just won't test / contribute / try stuff until we've got it
<lilmatt> foreign = non-MozCal?
<dmose> yes
<dmose> google calendar can subscribe to iCalendar files for example
<jminta_> makes sense to me
<jminta_> although, that work is almost entirely back-end
<dmose> especially now that google calendar is out there
<dmose> that is true
<dmose> perhaps we need front-end and back-end focus
<dmose> possible front-end focus could be performance
<dmose> since venkman got changes to work in tbird checked in yesterday
<dmose> and they may also be enough to make it work in sunbird
<dmose> (venkman can do profiling)
<garyvdm> I've got venkman working and have submited a patch
<dmose> thoughts?  reactions?  am i on crack?
<dmose> garyvdm: awesome!
<jminta_> dmose: my instinct is that the more severe bottlenecks will still be in the back-end, but it can't hurt to look
<lilmatt> dmose: No, I think it's good to split the focus that way until we figure out our user/app story
<dmose> jminta_: there's a bunch of low-hanging fruit w.r.t. batching, at the very list
<jminta_> true
<dmose> and the front-end profiling should be able to tell us which backend parts hurt the most
<dmose> at a very general level, anyway
<jminta_> ok, i need to go, i'll grab the log when i get back though
<dmose> ok, great
<lilmatt> dmose: and with xpfe out of the pciture there's also a bunch of low-hanging fruit w/r/t polish
<dmose> yeah
<ctalbert_> There is also the whole iTIP/iMIP/VFreeBusy stuff
<ctalbert_> And the QA organization changes (mostly to bugzilla and what not) that could be landed post 0.3a2
<lilmatt> and l10n move
<dmose> right, there's lots of stuff to workon
<ctalbert_> no shortage :-)
<dmose> i'm basically just suggesting that we organize the work so that we don't end up getting snarled in UI design issues that require us to have better sorted out our user / product / etc issues
<ctalbert_> dmose: I think that's a good idea
<lilmatt> Agreed
<dmose> because part of the work we'll be doing during this time is getting that stuff sorted out
<dmose> and by focussing on stuff that doesn't get mixed up in that, we'll buy ourselves a little time
<dmose> ok, it sounds like we have some approximate consensus from the folks here at least, we'll need to hear feedback from the folks not available right now after they see the meeting notes
<dmose> so, code factoring
--> bienvenu_ (DavidBienv@moz-90715E4.dsl.pltn13.pacbell.net) has joined #calendar-mtg
<dmose> there isn't really much to say here, other than that it's important to factor stuff such that it can be used appropriately by both lightning and sunbird
--> mhovis (mhovis@moz-2F355DBD.sw.biz.rr.com) has joined #calendar-mtg
<dmose> ctalbert and i were talking about this in relation to iTIP and iMIP a bit, and i just wanted to spread the word a bit wider
<lilmatt> dmose: on that front, I'm not focusing on abstracting out the shared pref pieces yet, only because of time constraints w/r/t 0.3a2
<dmose> so this is especially interesting with iMIP, for example, because sunbird is likely to want to send out iMIP mails, but by handing them off to the system mailer
<dmose> whereas lightning-in-tbird is part of the system mailer, most likely
<lilmatt> Yes.
<ctalbert_> So, we'd be doing MAPI calls, but we might not want to do MAPI calls if we're in lightning
<dmose> right, and as long as the interfaces are factored in the right places, this shouldn't be too hard, i don't think
<dmose> eg firefox can send mail using the system mailer
<ctalbert_> It's not on the wiki yet, but I factored out the iTIP Sending of mail into its own interface, so that will help in this effort
<dmose> as far as constructing the messages before sending, it's possible that the code could use the thunderbird stuff for that
<dmose> and then sunbird could do magic build/linkage tricks
<lilmatt> creating attachments, etc.?
<dmose> to suck in the required tbird code
<bienvenu_> I'd be happy to give advice if needed for doing that with TB
<ctalbert_> I'll take you up on that.
<dmose> that is likely to be fragile though, so if we can find a way to abstract out some interfaces that TB could implement and freeze, that might be a win
<bienvenu_> unless you're building complex messages, I'd recommend constructing the message yourself - it's not hard...
<ctalbert_> I've tried to implement the iTIP interfaces such that they can be completely controlled by prefs, and whether or not to use the system mailer could be just another pref
<dmose> great
<bienvenu_> though, if you use MAPI,  MAPI handles attachments
<mhovis> blech, Microsoft-specific code...
<bienvenu_> yeah, I was wondering what you were going to do for mac/linux
<dmose> bienvenu: i assume there must be code (used  by firefox) that abstracts out the platform specific mail-sending, no?
<bienvenu_> I don't know what Firefox does on linux/mac
<dmose> i'd say we definitely want to do that sort of abstraction if it all possible
<bienvenu_> it only does send link at this point
<dmose> right, but doing that has to be different on all three platforms
<bienvenu_> so it might use command line options
<mhovis> Prob. specific to KDE/Gnome/...Distro...
<dmose> anyway, we should very much try and make that an implementation detail if at reasonab le
<bienvenu_> yeah,  most likely
<mhovis> Isolate complexity
<ctalbert_> I think it should be possible
* mhovis is sorry for butting in.
* dmose chuckles
<dmose> it's all good
<dmose> ok, so last thing is next meeting
--> KaiRo (robert@moz-F2134722.gumpendorf.xdsl-line.inode.at) has joined #calendar-mtg
<dmose> i vote for same-time next week
<lilmatt> seconde
<ctalbert_> third
<dmose> ok, sounds like we're all set
<mhovis> fourth, I'll do better at interacting with all you guys.
<dmose> :-)
<dmose> meeting adjourned
<dmose> (woot, on time even!)
<ctalbert_> :-))
<-- bienvenu_ (DavidBienv@moz-90715E4.dsl.pltn13.pacbell.net) has left #calendar-mtg
<-- lilmatt (lilmatt@moz-775380E8.twcny.res.rr.com) has left #calendar-mtg
<-- mschroeder (mozilla@moz-99D9708E.dip0.t-ipconnect.de) has left #calendar-mtg
<-- mhovis (mhovis@moz-2F355DBD.sw.biz.rr.com) has left #calendar-mtg
<-- ctalbert_ (chatzilla@moz-2F355DBD.sw.biz.rr.com) has left #calendar-mtg
<-- KaiRo (robert@moz-F2134722.gumpendorf.xdsl-line.inode.at) has left #calendar-mtg (www.KaiRo.at)
<-- garyvdm (chatzilla@moz-63B5BB09.telkomadsl.co.za) has left #calendar-mtg
<-- muhjiko has quit (Quit: Chatzilla 0.9.70 [Firefox 1.5.0.1/2006011112])