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.'"
other calendaring solutions (Score:3, Interesting)
What about (Score:3, Interesting)
Will it sync with Outlook Calender? (Score:1, Interesting)
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
Re:its the biggest difference between Outlook (Score:5, Interesting)
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.
What's needed is better interprocess communication (Score:3, Interesting)
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.