Great Unsolved Problem In Computer Science

http://algeri-wong.com/yishan/great-unsolved-problems-in-computer-science.html

by nopinsight • 15 years ago

155 55 15 years ago

algeri-wong.com

Maro3• 15 years ago

Some more info on why handlist dates is hard (I didn't write it):

http://planetlotus.org/profiles/mikkel-heisterberg_87315_why...

lloeki2• 15 years ago

Probably this comes from the fact that planning appointments across timezones (especially potentially shifting ones) while trying to speak local time is doomed.

Personally I use this simple rule: - if the meeting is local, use the meeting physical location local time. - if the meeting is global, use zulu time.

Now that doesn't help that calendar software actually fails to allow someone to do that properly and easily, but to me that's an artifact of the time notation system we use which grew overly complicated because we insist on tying time to the sun position (for various reasons, some being legitimate, some not really).

Although I despised the marketing aspect of it I actually like the Swatch internet time concept and .beat unit. It just makes sense, is deceptively simple and while it duplicates the role of zulu it removes any source of possible timezone confusion when you write a time (and don't want to sound like a military or an air traffic controller when appointing someone at 0900Z)

omh3• 15 years ago

if the meeting is global, use zulu time

Do you really use this in conversations/emails etc?

I can't imagine many non-technical people being happy to deal with describing meeting times in this way.

Of course software can (and generally does) use something like this internally, but local software will then be expected to convert it back to local time. And to do that, you get the problems that the grandparent post describes.

This gets even worse as soon as there is one bug out there. I've seen problems where Outlook gets confused about daylight saving, or where someone travels with their Blackberry and changes the time rather than the timezone. As soon as people have seen one meeting with the 'wrong' time they'll start to distrust the ability of the software to manage things and then we're back to square one.

hm2k2• 15 years ago

There is more than just two companies, there always has been.

* Apple released iCal in 2002.

* Mozilla announced their calendar project (Sunbird) in 2003.

* In 2003 Novell purchased Ximian and their calendar software: Evolution

zyphlar• 15 years ago

Those are calendar clients. Now ask Mozilla to write a calendaring server that syncs with every mobile device on the market across 150 calendars some of which have many thousands of appointments each (with years of exceptions to recurrence) -- no mistakes allowed. Also meeting invitations.

This one issue might be what keeps Microsoft in the game.

cookiecaper2• 15 years ago

As usual, Microsoft's wide compatibility is less a function of their effort and more a function of their marketshare; if your stuff doesn't work on Windows, you break it until it does because if you don't work with Windows/Outlook/MS, you're locking yourself out of 90%+ of the market. Hence, MS is always the standard unless you don't care about that market, and there aren't many for-profit companies willing to forgo such a large base of potential customers.

mryall• 15 years ago

Actually, Apple makes an iCal server:

http://www.apple.com/server/macosx/features/ical-server.html

And Novell GroupWise is the server-side product from that company which does calendaring:

http://www.novell.com/products/groupwise/features/#calendar

There are definitely alternatives, depending on what functionality you need.

hm2k2• 15 years ago

I also forgot to mention Yahoo! who bought Zimbra, which pretty much covers what you just mentioned through and through.

Also see: http://alternativeto.net/software/microsoft-exchange-server/

whatusername• 15 years ago

As guelo wrote: Lotus Domino and Groupwise. (Not tomention facebook)

bruceboughton2• 15 years ago

Lotus Notes is a solution in the same sense that suicide is a solution to being sad.

guelo• 15 years ago

Other companies have solved this problem at the enterprise level with huge installations, most notably Lotus Notes and to a lesser extent Novell Groupware.

In the non-office space Facebook is making a strong run at the defacto group scheduler, at least among my network.

omh3• 15 years ago

most notably Lotus Notes

Some people, when confronted with a calendaring problem, think "I know, I'll use Lotus Notes". Now they have two problems

lsb• 15 years ago

Some people, when confronted with a calendaring problem, think "I know, I'll use Lotus Notes". Now their subordinates have two problems.

gadders2• 15 years ago

I used to work for Lotus and was a Notes developer. But funny is funny.

Seriously I'd say it's no better or worse than any other group scheduling app like Outlook. TBH, email isn't really a source of competitive advantage for a company. It's on a par with a phone service or electricity. Just outsource it to google already.

bguthrie• 15 years ago

Much the same way Microsoft has Exchange as its server backend and Outlook as the client UI, Lotus has Domino as its backend and Notes as its frontend. Domino is a pretty good product. It's fast, secure, distributes well, was one of the first products to employ a document-based database, and it's backwards-compatible across something like fifteen years of its database format. Every sysadmin I know loves it.

Notes, in contrast, is now a wretched mess, having failed to correct for fifteen years' worth of poor UX decisions.

Taken as two independent entities, the calendaring in Domino is excellent. Notes makes it a pain to deal with, but Domino does a good job of solving the hard bits. So there's a good argument to be made that Lotus has made a successful go at this, but I wouldn't give Notes the credit.

yuvadam• 15 years ago

Just throwing an idea out there -

Is it possible to create a distributed calendar system based on git? Think about it, all the plumbing is there. Represent calendar semantics in a logical way, and you also have meeting collision (i.e. conflict resolution) support.

bruceboughton2• 15 years ago

Git might address some of the technical requirements but it has nothing to offer for the functional requirements.

"Is it possible to create a cheesecake using moondust?"

jimktrains2• 15 years ago

To be fair the grandposter's idea does solve half the problems posed by the article.

scythe• 15 years ago

"Is it possible to create a cheesecake using moondust?"

How about stardust?

snprbob862• 15 years ago

My product involves scheduling of reoccurring reminders, deadlines, etc. Handling of timezones in particular has been an incredible productivity black hole.

Side note: Who do I need to pay off to get a Olson timezone header added to the HTTP spec?

bhousel3• 15 years ago

Why? A few lines of Javascript can tell you which timezone the user's machine is set to. Add a timezone dropdown field to the form where they enter the meeting details, and default that field to their local timezone, but let them change it. Javascript can also tell you whether the meeting date that they picked occurs during DST or not (in the local timezone), store that information in a hidden field.

Now you have everything you need to schedule the meetings and make them appear correctly for everyone involved: The date and time of the meeting, the timezone of the meeting, whether or not DST is occurring there at that date and time. Store everything in the database separately, and store all datetimes at UTC.

This is the solution I built once for an "enterprise" client†, and it worked pretty well.

† a global lawfirm, who regularly needs to schedule meetings across timezones.

DCoder• 15 years ago

Were those recurring meetings or one-offs?

Part of a product I'm working on now is being able to schedule repeating tasks every day, every month, etc. Which means that "07:30 every Friday" has to happen at 07:30 in the author's timezone, whether or not DST is active. To my knowledge Javascript can only tell you the timezone offset from UTC for a given date/time. You can determine the DST-less offset that way, but there are multiple timezones sharing the same offset (e.g. PHP has 63 separate timezone records for Europe alone) and then simply matching them by offsets doesn't work ideally, you need the user to make a choice.

snprbob862• 15 years ago

A few lines of Javascript can tell you which timezone the user's machine is set to.

That is simply not true. You can get the localized timezone as provided by the user's operating system. You would need a server side mapping of every time zone in language for both Olson and Windows. Even then, there are ambiguous timezone names, etc.

The best you can do reasonably is calculate GMT offset, presence of daylight savings time, and if DST is present, then which hemisphere the user is in. From there, you can guess at a city/region with the largest population.

See here: https://bitbucket.org/pellepim/jstimezonedetect/overview

temptemptemp13• 15 years ago

What does this have to do with computer 'science'? Sounds to me like he's talking about 'engineering'.

rednum• 15 years ago

Either none of us gets the irony or it's simple misleading. Personally I was expecting complexity/algorithm article starting with overview of P ?= NP followed by some other less known but interesting theoretical issues.

muyuu• 15 years ago

I don't see it as a problem of CS, but management. It's a problem we've made all by ourselves.

Absolutely any problem involving humans where errors MUST be kept at ~0% in all cases (any you have just a bunch of variables that can combine and permute) becomes extremely hard.

If you add a ton of features to it, then it becomes intractable.

In my company, all meetings are set in GMT and a notification is sent as soon as the meeting is decided, which is never less than 3 days in advance. After that, it's not any software responsibility to attend to this meeting and it doesn't matter whether you received a reminder or not. You keep track of your local time. If your country decides to switch to the Mayan Calendar it's not my f*g problem, you keep track of GMT time. Period.

pyrhho• 15 years ago

How is life at Initech?

TwoBit• 15 years ago

I think the author is a fool for making claims about how comparatively hard large programs like Word and Excel are without having any such experience. Reminds me of the fool last week who was making claims about commercial game development practices without knowing anything about it.

retube2• 15 years ago

There wasn't much in the way of meat in that post, unless I missed it. As far as I understood, the problem with calandering is:

- Synchronization: with potentially gazillions of users on a single network you've got a timeliness problem: User A may look free to User B, so he books User B, but actually in the interim User C books User B, so there's a conflict. Given the graph-like nature of such a network (all nodes potentially linked to each other) such conflicts could quickly ripple through the system.

Sounds interesting, I wish the author had been a little more specific about the problems.

Maro3• 15 years ago

I wouldn't think the cross-scheduling issue is actually a huge practical problem, as it requires fairly specific failure cases. OTOH if the users are disconnected, then you can't solve the problem anyhow, so you just write a consistency checker that runs while/after syncing and alerts users.

I think the real problem is sheer engineering complexity: having to support a large number of input/output formats, protocols, devices, locales, languages, countries, timezones, platforms, legacy features, backward-compatibility, tools, etc. and making it all look good on the desktop, web and mobile app.

I think the OP is saying if you multiply these together, then you're screwed, unless you're Microsoft or Google...

retube2• 15 years ago

Right. That makes more sense. But none of these are CS issues - as you say they're engineering ones. Some self-healing conflict resolver otoh is probably closer to a cs problem.

Maro3• 15 years ago

The high profile startup Asana is attacking problems like this. One of their advisors is Mitch Kapor, the founder of Lotus and designer of Lotus 1-2-3.

gadders2• 15 years ago

Is that different to Chandler, or is he having another go at it?

cschmidt• 15 years ago

Wow, I just looked at the company profile. That's some list of advisors. They must have more money than they know what to do with, and sit on very nice chairs.

qntm• 15 years ago

I wish this person had been more specific with respect to the specific problems with calendaring. The ones raised in this article look reasonably straightforward to me. "Thousands of machines, each one run by a human, most of whom are probably illiterate in computer skills and pretty much randomly clicking here and there willy-nilly" is pretty much the internet, right?

mhansen• 15 years ago

Hasn't Google Calendar solved this?

gulbrandr• 15 years ago

> Why is calendaring hard? Well, [...] the product requirements [...] some sort of ridiculous amount of distributed systems hackery around timeliness of updates, heterogenous network, consistency, graceful exception handling, and node availability semantics.

I'm sure Facebook, Google, Apple or Twitter can do that.

tytso• 15 years ago

One of the most annoying thing is getting timezones right when you try to exchange calendar invites across systems. (i.e., sending a Lotus Notes invite to Google Calendar, or an Evolution invite to Novell's Groupwise, etc.)

There is an IETF standard for the calendaring exchange, which is why it works at all (albeit badly), but unfortunately, when you are trying to coordinate a meeting schedule across multiple calendaring systems, you're very likely to have the global calendaring problem where time zones matter. :-(

robfig• 15 years ago

tl;dr Calendaring is the only program that requires distributed coordination in the Microsoft office suite, so it is the hardest to make.

Can't argue with that. But all of the difficult problems mentioned in the post are difficulties with any distributed system, not specific to calendar at all!

Microsoft has probably been having those same issues with Word, Excel, even Powerpoint as they have been working on making them collaborative for a long time now...

larrik• 15 years ago

No one pointed out that this article is actually 2 years old, but that does make a difference to me.

I kept thinking of something the founders of Justin.tv said:

We were too easily distracted and hadn't really thought through the strategic implications of owning a standalone calendaring property (hint: no one wants a calendar without email).

JacobAldridge• 15 years ago

I remember that Kiko was the first YC company I really cared about and rooted for. Their approach to this challenge was spectacularly pummeled from a timing perspective by the entry of Google (iirc), and from what I understand the guys have gone on to create some other, very excellent businesses (including Justin.tv).

I think it's interesting to note that five years on, the calendar problem remains.

(Happy for the Kiko team or those who actually know them to correct my memory; and for those with no such memory - http://techcrunch.com/2006/08/16/ajax-calendar-kikocom-goes-...)

Edit: While I was typing Larrik made his comment. So interesting to note that 2 years ago this problem still remained, and it's worth clarifying that Google's entry wasn't the only (or even main?) reason for Kiko's end.

known• 15 years ago

http://en.wikipedia.org/wiki/List_of_unsolved_problems

podperson• 15 years ago

"word processors are probably the easiest" hahahaha.

Microsoft has been working on Word longer than it has been working on calendaring, and it still sucks too. I think the problem is the underlying assumption that Microsoft is the world's greatest software company.

Apple pulled Pages out of its ass in nothing flat, and it's a better word processor than Word. (Framemaker is also a better word-processor than Word, but it's kind of expensive.)

gatlin• 15 years ago

fta: "How do you handle exceptions to recurring meetings?"

If the user says "No meeting this Thursday," don't show the meeting on Thursday? Did I miss something? /cocky youngster, question stands

Jupe• 15 years ago

I disagree. I believe MS Project is a much larger/more complicated animal - at least when using Project Server.

How do you handle exceptions when a task update is accepted by a timesheet manager, but rejected by the project manager, all while the data was written to the back-end reporting cube?

Have you ever tried to level a resource on four competing projects? This is much more complicated than scheduling meetings using a single-use resource like a meeting room.

viraptor• 15 years ago

> But we've been working on calendaring for maybe 20 years now, and Outlook/Exchange still sucks.

I'm still not sure whether it says something about the calendaring problem, or MS software design. As much as I'm happy with outlook/exchange in general, my outlook crashes ~4 times each day. I tend to blame MS being sloppy, not calendaring being hard in that situation.

Great Unsolved Problem In Computer Science

Related Stories