Become a fan of Slashdot on Facebook


Forgot your password?

Mozilla Lightning 0.1 Released 198

Mini-Geek writes "MozillaZine is reporting that Lightning 0.1 is released. Lightning is a new Mozilla-made calendar extension for Mozilla Thunderbird that will eventually (once it becomes more mature and stable) be built into Thunderbird. From the article: 'The Lightning Project is a redesign of the Calendar component. Its goal is to tightly integrate calendar functionality (scheduling, tasks, etc.) into Mozilla Thunderbird.'"
This discussion has been archived. No new comments can be posted.

Mozilla Lightning 0.1 Released

Comments Filter:
  • by slackaddict ( 950042 ) <rmorgan&openaddict,com> on Tuesday March 21, 2006 @12:40PM (#14964709) Homepage Journal
    This question is aimed at those who use this type of software heavily: how does the Mozilla option compare to some web-based solutions like, say, the calendaring option for the SquirrelMail project?

  • What about (Score:3, Interesting)

    by Kelz ( 611260 ) on Tuesday March 21, 2006 @12:43PM (#14964729)
    Corporate functionality? I'll be quite a few IT people would love to see a viable open source E-mail/corporate calender program (though MSO is so entrenched in many systems it would be damn near impossible to uproot it now...). This could be a big plus for newer businesses.
  • by Anonymous Coward on Tuesday March 21, 2006 @12:47PM (#14964768)
    It will be really good, if it can sync with existing Outlook calender invite.
    Ex - You get a calender invite from outlook - your mozilla calender gets updated.
    Similarly when you send a calender invite, it should be able to sync with others outlook calender in the same way. (i.e. calender invite from lighting setting up schedule in outlook calenders)

    Since I am among the very people who use thunderbird in the office, and it is very *very* difficult since everybody else sends meeting requests in .ics formats.
  • Group sharing of contacts, resources, etc?

    Scheduling with multiple complex calendars? Meeting invitations and e-mail reminders seemlessly included (and able to be sent from one outlook client to another)?

    A lot of that is based on the fact that you're using outlook as an exchange client.
    I definitely believe that Exchange is a steaming pile. It crashes frequently and has severe problems when the data in it exceeds a certain size for no good reason. Occasionally it corrupts itself.

    It takes an expert in Exchange to administer despite the fact that the tasks that it is designed to handle are relatively simple concepts. (In contrast, SQL Server, which does something far more complicated to understand is actually easier to administer, IMHO, because it mostly works right).

    However, at a lot of places we're all stuck with it, and with Outlook, until we've got a complete scheduling and e-mail solution that has features that are close.
  • by Animats ( 122034 ) on Tuesday March 21, 2006 @01:37PM (#14965207) Homepage
    One huge problem in the Linux world is that there's no standard approach to inter-application communication. The Windows world has had a single solution for fifteen years. (One can argue that COM isn't very good, but it's always there.) OpenOffice uses their own implementation of CORBA. Firefox and Mozilla have some private intercommunication scheme. Most other programs don't talk well at all.

    This is an old, old problem with UNIX. In the beginning, there were pipes, which are unidirectional. There were signals, which were badly botched in early UNIX, resulting in several redesigns, all different, with the end result that nobody could trust signals. Then came sockets, which were bidirectional but oriented towards talking to services on remote machines, not interprocess peer to peer communication locally. There's still no standard, always-there way for one program in the UNIX world to call another and get an answer back. There are about five CORBA implementations, there's OpenRPC, there's Java RMI, and there are a few other schemes not used much. But mostly, there's not much talking back and forth, other than at the file and pipe level or to a remote server.

    I often wonder how UNIX history might have been different if a facility for this had been there from the early days. In UNIX, one program can invoke another, passing a set of command line arguments and environment variables. But all that comes back is a return code. How different it might have been if you got back output arguments. Then programs could have called other programs as subroutines.

    Or if UNIX/Linux had had good interprocess communication from the early days.

Loose bits sink chips.