Posted
by
Hemos
on Monday August 07, 2006 @09:21AM
from the chander-fritz dept.

RobotRunAmok writes "Before there was Outlook, or Evolution, or The Brain, there was Lotus Agenda, a DOS-based Personal Information Manager created by Mitch Kapor. Wired is reporting that Kapor is throwing 5 Million USD at the Open Source Applications Foundation to create an open-source resurrection of this PIM-Of-The-Gods in the form of Chandler, available now as an alpha for Windows, Linux, and Mac.
For the Agenda hardcore among us, it's as though Atlantis is rising..."

From a developer's point of view it's a framework for networked apps. On top of the framework it's easier to write chat clients, email clients, RSS readers, etc. that are all connected in some way (e.g. email sender links to chat client).

From a user's point of view it can be an integration of all of your PIM applications. Data from various sources can be viewed in a variety of ways. I think the idea is to create more open and dynamic ways of viewing and integrating the data. I think the developers are sort of hoping new ways of working with emails, RSS, and other data are invented as a byproduct.

Agenda was revolutionary in my view. It was not a PIM in the sense of an address book/email program. It was a freeform database that you could dump text data into and manipulate in ways only limited by your ability and imagination. To this day, there have been no programs released with Agenda-like functionality.

yeah, I bought a copy of Agenda sometime around 1988 for something like $400.I remember liking it a lot but realizing that the possibilities it offered were far beyond the ability of most mortals to master.

Remember, PIMS were a hot market prior to Windows 3.0 - but most products were never ported to Windows because there wasn't enough revenue being made. This was because users would buy the hype, buy the product but weren't commited enough to get past the learning curve and dedicate time to maintaining dat

Agenda was revolutionary in my view. It was not a PIM in the sense of an address book/email program. It was a freeform database that you could dump text data into and manipulate in ways only limited by your ability and imagination. To this day, there have been no programs released with Agenda-like functionality.

An accurate assessment, IMNSHO. (I worked on Agenda 1.0.) It's an interesting footnote that the term PIM (Personal Information Manager) was originally coined in a paper about Agenda published in

True. A couple of years ago there was a dearth of open source PIM software out there. Now there's quite a bit. For the AJAX-minded, there's server software like Citadel [citadel.org]. For those who want a fat client, there really isn't anything better than Kontact [kontact.org], which really has come into its own with end-to-end PIM and groupware functions. Put the two together and you've really got an end-to-end solution.

Unfortunately some of us have to run on Windows (yeah, I know about WINE, etc. etc., trust me on this). I am looking for something like Kontact that runs on Windows without actually using Outlook. Chandler is a start, but only that at this point. Any other ideas?

I hate the way dragging a To Do to your calendar actually removes it from your To Do list. It should copy it as a new calendar entry, which can then be manipulated as you see fit without changing the original To Do.

Thanks for clarifying. When I read that "Wired is reporting that Kapor is throwing 5 Million USD at the Open Source Applications Foundation" -- I saw the phrase "Kapor IS throwing 5 Million USD" and assumed something new is happening with this project.Sometimes it does matter what the meaning of the word "is" is.

When the OSAF announce Chandler a few years ago, I was looking forward to a decent Cross-platform Open-Source PIM. Now, there seem to be a couple dozen PIM applications on the horizon--- including

"For the Agenda hardcore among us, it's as though Atlantis is rising..."

That's pretty good and all that, but you're really never going to be able to get the dead fish smell out of the place. You're also going to have to contend with lawsuits from Namor and Arthur Curry as soon as you set foot in it, too. Best advise your lawyer to play those two off each other.

The PIM I used in the DOS days was SideKick [wikipedia.org]. The great thing about it was that it was a TSR; you could leave it running in the background and invoke it with a few keystrokes. It would then pop up on screen in front of the DOS application you were running, and then return you to your previous state afterwards. I never used the Windows version; once the OS was multitasking the killer feature had gone.

Reading the Wikipedia article about Agenda, it sounds very much like the PIM functionality of the Apple Newton, particularly the Agent. I wonder how inspired the Newton designers were by Agenda.

The great thing about it was that it was a TSR; you could leave it running in the background and invoke it with a few keystrokes.

Unfortunately, that was also what (sometimes) sucked about it. It would eat nearly have of your precious 'real memory' (>640K) and, even more unfortunately, it seemed to have a problem with many extended (EMS/XMS) memory managers, including the popular QEMM/386 from Quarterdeck.

XTG under DOS was the killer app of it's day, but never actually made it to usability on Windows.

A close contender these days is Resco Explorer [resco.net] for the PDA, which does everything you could ask for.

To bring this post back on topic, the killer app for me on the PocketPC is Pocket Informant [pocketinformant.com]. If this will sync up to Chandler then us PDA users can drop the horrendous ActiveSync/Outlook combination that is the only way to manage PIM data between mobile a

ztree is a clone of XTG & still uses a CLI. The XTree Company did release an officical XTG for windows, which did very poorly (as it was a poor product). The XTree Company was aquired by Central Point Software and then by Symantec, who was pushing Norton Commander (which also eventually died).

I had forgot about XTG for windows (I don't think it had the CLI), but now I remembere what a dog it was. Most of us just got the DOS version working on windows and stayed with the 8.3 file naming for a few years. It had some great viewers. It even had an AutoCAD one. Ztree can use external viewers.

You'd think with all the PIMs available these days my memory might be okay, but nope, I'd completely forgotten that I used Sidekick until I saw your post!Am I the only one who's a fan of 'dynamic scheduling' in PIMs? I think something as original as dynamic scheduling might be a way for an open source PIM to stand out from the rest of the crowd. In most PIMs, tasks and appointments are independent of each other, with the result that you can never easily be sure how far forward your workload extends, but the

Like it had little compatibility with other apps, had memory and file limitations, and had an ugly GUI.Maybe OSS'ing it might improve it, but by the post, you'd think the Rapture was upon us. It's not. This code will take a lot of work to make right, It was developed in an era where code wasn't checked much for array bounds, and if memory served (I used it and kind of liked it) it had little code for large files (pics and video) and had no knowledge of a number of varying kinds of file types for linking, im

All of the limitations you're talking about were common to apps of Agenda's day: they're certainly not unique to Agenda. One can expect that if Agenda was resurrected it'd share the traits of modern apps and lose those limitations.

Also "a lot of freaking work" is exactly what the $5M is for:-) That much money gets "a lot of freaking work" done.

Anyway, I don't believe Chandler is going to be an updated Agenda: I think it's a new animal that will share a lot of the features and strengths that Agenda

Like it had little compatibility with other apps, had memory and file limitations, and had an ugly GUI.

Agenda was an MS-DOS product, which meant that: a) it was a standalone application with relatively few opportunities to be compatibile; b) it had memory and file limitations inherent with being a DOS application; and c) it didn't have a GUI. The UI it did have was, admittedly, ugly.

These limitations, whether the fault of the Agenda implementation or not, certainly contributed to its demise. To succee

So far, they've only managed to produce alpha quality software at best, after more than three years. I always felt that they made some bad technology decisions from the start, like Python is probably not the best language for writing a PIM.

The requirements for this project have gone all over the place. Initially, it was touted as "exchange without the server," using some P2P method. Then it became an "outlook killer," then a "repository," and now they even have a "higher ed version," thats been talked about for some time.

Instead of trying to do a few things really well to start with, this project has become the poster boy for scope creep.

Why is Python a bad choice? It's just a high-level OO language with lots and lots of libraries. Speed shouldn't be an issue with this sort of application. Whatever GUI library they use is surely written in C or C++ with Python bindings. Also, training developers to use Python is very easy (lots of personal experience), especially if they already know Java, C++, or C# pretty well.

Would you have chosen C, C++, or Java or... what? I think that if the project is taking too long, Python, or any other language like it, would be the last thing to blame.

It's too slow. You say that doesn't matter in "an app like this" but performance always matters. If you are competing for users then performance matters, it's as simple as that. You can get away with crap performance only if your app is so unique or valuable that people will tolerate the lack of it. I don't know if this is still true but at one point Chandler took over a minute to start up. The whole point of a PIM application is to collate and present a potentially larg

Python would have been a good choice if they were going to rapidly develop Chandler - once they had a working app, they could go through and move parts to C/C++. So they could get Chandler out the door and conquoring the world quick, and then optimize later. But if they had rapidly developed Chandler, you would think they'd be working on version 2 by now. Seeing as the project is moving at glacial speeds with python, it makes one wonder if they would even have released version 0.1 by now if they were writing in C++.

I think Python is only rapid if you are working at a certain scale, beyond that you start to go "hmm we can't really release beta 1 when it takes 500mb of RAM to get to the welcome screen", so you end up sinking a lot of time into optimisation and profiling; worse people who chose to go out on a limb and use Python for everything probably aren't going to sit down and go "Huh, maybe we should rewrite large chunks in C++". So it's rather self defeating for very large projects.

There is only one language suitable for writing complex client-side software and that's C++: anything else doesn't have the performance characteristics necessary.

I call bullshit as long as you don't back this up with numbers. They point is, even in C++ you are normally using the (native) bindings to you GUI library of choice. That means that the dominating factor for speed of the GUI is the speed of the GUI library, because in most cases your backend code will not be time intensive.In Python/Perl/Ruby etc.

Numbers? Sure, how many popular desktop apps are written in Python? Zero, right? And how many in Java? Well, only Java IDEs really, then you have that BitTorrent client and I think LimeWire used to be written in it. Maybe still is. I can count them on my fingers. Now look at newly developed apps - Picasa, Skype, Google Talk, World of Warcraft etc. C++, all of them.

I was not talking about python vs. C++! Clearly, C++ wins here in number of applications its based on. I was criticizing what you said, repeated here for your convenience:"There is only one language suitable for writing complex client-side software and that's C++: anything else doesn't have the performance characteristics necessary."

See? It's not about Python vs. C++, per your own words.Btw. WoW uses TCL in the backend, Battlefield 2 has python hooked in for scripting, where you can script _everything_, not

I realised after I posted that I should back this up with some argument instead of just pointing to newly released commercial software.

The idea that if you have a fast GUI toolkit you can bind to it and use slow and inefficient languages is popular but IMHO wrong. Consider - most interesting apps actually do some work beyond putting widgets on the screen, usually manipulating data of some kind. The string "Hello World" takes about 61 bytes in Java (probably slightly less in Python but you have more of th

It only takes 12 in UTF-8 as well of course. Besides, you only need to use Unicode strings when you know it might contain non-ASCII characters. If you are reading, say, an XML file using a schema of your own devising, then you can say with certainty that there is no need to store the tag names using double byte encodings - this "one size fits all" string encoding choice of Javas is questionable and a serious resource hog.

Yes, I played with D a year or so ago. It's really nice and hopefully one day I'll get to write desktop software with it. It provides most of the benefits of more modern languages without the downsides.

It's too slow. You say that doesn't matter in "an app like this" but performance always matters. If you are competing for users then performance matters, it's as simple as that.

Can you give any examples of this wrt to Python? Having used several Python based applications. If what you say is true, then they would necessarily be slow because of Python. If Python doesn't imply slow, then what you are saying doesn't mean anything.

Most performance problems these days are architectural; you have lots of compute

I can't imagine Chandler needing to perform FFTs, and if it does there are bindings for other languages. How fast does your "wait for user input" loop need to cycle, anyway?

You can die a death of a thousand cuts. The idea that you can optimise a few hotspots then use something slow/inefficient for the rest just doesn't work when everything needs to be tight (like on desktop apps). Not me saying this, talk to the Unreal Engine authors about it.

I can't follow your argument. You tried to write an FPS in Java and think that somehow proves that C++ is the only viable option for writing GUI applications? Exactly what do you think Chandler does anyway?

I've never used Chandler, but I've used Evolution and I've looked at some of its performance problems. Granted, it's mostly C code, but they're the same kinds of errors I would expect to see in any language -- bad caching, very poor r

And finally I have tried to profile a Python app for memory usage, but gave up when I discovered that Python doesn't even try to be efficient with memory usage. No point trying to optimise the main app when the runtime makes memory inefficiency pervasive.

It isn't correct that Python does not attempt to be efficient with its memory usage. You mentioned before that you had heard of PyMalloc. What is PyMalloc for? "Pymalloc, a specialized object allocator written by Vladimir Marangozov, was a feature added

Speed is an issue with this type of application, as it is with all applications. I tried the beta about six months ago. It was slower than molasses in January. It took over a minute to initially load and then the UI was sluggish. The amount of frustration that I experienced as an end user was incredible. The other part of the beta is that the only part that was working was the calendar. I was using the 0.6 release and I haven't yet seen what is new in the 0.7 release. It is not even a minimally funct

according to your resume, you have never even used Python. So, how would you know? Just because it's not your favorite language (which is apparently Java) doesn't mean that it's not any good for the job.

Python is a great choice for a lot of applications, but I think its a bad choice for A PIM. I never had a job working with python directly(zope, mailman, indirectly). I don't claim to be a python expert.

As far as Java is concerned, that is also a language I wouldn't use for writing a PIM as well.

The reason for the "progress" so far is that the folks working at OSAF are all senior people, some already "independently wealthy". Consequently you get lots of high level design (or as Joel calls it, Architecture Astronauts) but not much actual real work.

Python is a good language for writing a standalone PIM. However I question the point of a standalone program.

Today you can't tell if email coming from Amazon.com is important unless you also have been watching my web browsing. If I was there in the last few days then I'd be excited about what is shipping to me. Conversely if I haven't been in years, then it is spam. A good PIM can only be worthwhile if it takes into all of your activities over time with whom you communicate and that must take into account web, blogs, mail etc. The problem today is not storing information, but making sense of it and working out which is more valuable and when.

The reason for the "progress" so far is that the folks working at OSAF are all senior people, some already "independently wealthy". Consequently you get lots of high level design (or as Joel calls it, Architecture Astronauts) but not much actual real work.

That's true. They've spent a bit of time getting base libraries for Python that would have been a non-issue in other languages.

What libraries are those? wxPython existed before Chandler and twisted was independant (I'm not certain which was first - twisted or chandler). I know they've created a library for http and [web|cal]DAV - but such code has existed for python for a while so I'm guessing they just wanted something easy to use and all in one place.

I remember P2P, repository, and higher ed versions in the initial (0.1) roadmap...They had an incremental plan for developing the basic functionality, then simple p2p calendaring, then a server-based repo, then the "higher-ed" version (a not-quite-ready-for-enterprise release). I haven't checked in on them for a long while, but it now looks like they're right in pace with their initial roadmap.

I didn't think it would take them this long, but they are making progress. Not every OSS project has the speed and

Aside from the Kapor tie-in? Agenda's key feature was that you could just take notes and it'd see, "Meet with Dave next Tuesday about project x" and it'd know which Dave based on the Project X team and when next Tuesday was based on today's date, etc. Then it'd categorize all your notes so you could ask it, "Show me Project X stuff" or "What appointments do I have today?" If this is just an alternative to Outlook - that is, calendar-oriented or whatever -- how is it Agenda-like?

It's named after Raymond Chandler, the mystery author. This is the URL [osafoundation.org] that explains briefly in their own words:
"Our product (code-named "Chandler" after the great detective novelist Raymond Chandler,) is a Personal Information Manager (PIM) intended for use in everyday information and communication tasks, such as composing and reading email, managing an appointment calendar and keeping a contact list."

Well, I knew the meaning of the word already from old RPG Harn, which is why I was curious - the first PC I created for that game started as a chandler (and it SUCKED - especially playing for 3 sessions before he even had RPG-useful skills... then he died and I played an NPC healer we rescued for the rest of the sessions, but I digress). Anyhow, the osa site was either slashdotted or incredibly slow at the time, so I couldn't really look to see it was named after Raymond Chandler (the detective novelist) a

Honestly, This seems completly behind the time. The lesson of Gmail is that uses will accept less functionality in exchange for more universal access. Take a look at Zimbra if you want to see a real exchange killer.

Drop me a line when that app is revived as open source. It was a unique spreadsheet app that I have yet to see replicated anywhere. If my memory serves me, it was actually developed for Next and quietly went away.

On the other hand, my recollection of Organizer was when it came bundled on my old Hitachi laptop, circa 1996. I found it to be mostly "cute" with its binder metaphor but otherwise nothing special.