EccoProWiki: CodingIssues

From: Steve

   Subject: [eccopro] Re: Ecco Open Source Initiative

   At this point NetManage? is interested determining if any 
   software developers would like to contribute to the further 
   development of the source code as an open source GPL or LGPL 
   licensed product...

I would likely get involved if this comes to pass. Personally I'd be more interested in licensing along the lines of Apache than in a straight GPL. Since I'm a professional developer, I generally avoid looking at GPL code unless the application is significantly outside any areas where I might be working. I do find the LGPL more reasonable.

Dave

In eccopro@yahoogroups.com, two.olives@g... wrote:

   I've been following with some interest the occasional discussion regarding
   Netmanage possibly open sourcing the app, and I'm dissapointed that
   more progress isn't being made (although I can't especially blame Netmanage).

Ben then, they've been sitting on the source code since 1997, so they aren't known for speedy decisions anyway. No feedback since November, either positive or negative, so it's pretty likely that talks are still under way, or I would have expected whoever from this group is engaged in the talks to tell us how it went.

Now, if Ecco is indeed open-sourced, I wonder if the code will be in a good enough shape to resume coding, or if it'll only be useful as a source of ideas but must be rewritten from scratch.

Fred.

Despite the lack of visible progress, Jeff Sonnabend seems to be working hard on the open source angle, and he deserves a lot of credit for getting the ball rolling on that and pursuing it. If Ecco is ever open-sourced, I personally pledge to get it compiled and working on Mac OS X with Darwine (I already use Ecco on OS X under Virtual PC, but a native Ecco would be great).

As for your main question: a new, built-from-scratch Ecco would be a tremendous amount of work. It's hard to really appreciate how good Ecco is, both from the perspective of being rock solid and bug free, as well as having a very polished, usable user interface (complete with tabs, the current fad in the UI world) unless you scout around looking at the competition. Spend some time with Microsoft OneNote?, or OmniOutliner?, or Aquaminds Notetaker, or Circus Ponies Notebook, or ADM, and each one has some pluses and flashy features, but there's always something that kills it, either from a UI perspective or a stability perspective (e.g. OmniOutliner? is powerful, has columns, and is programmable, but has some extraordinarily annoying scrolling bugs). Remember that Ecco had seven years of testing and bug-removal by a dedicated team of testers at Arabesque and Netmanage. If we started building Ecco from scratch, there would be a period of at least a couple years where the program would be quite buggy, and there is no guarantee that the UI would converge to something truly usable unless there were some very dedicated programmers on the team who care about usability. I just don't think it would be worth it, given that Ecco works great now and will likely continue to work well into the future.

The real motivation to build Ecco from scratch would be to add new features, but what really does Ecco need that can't be implemented through its current scripting engine? I've thought about this a lot, and most nontrivial features would seriously complicate the user interface. The obvious new feature would be arbitrary clones (i.e. allowing items to have more than one parent), but aside from breaking the whole elegant outline metaphor that exists throughout Ecco, this one feature would add user interface complications throughout the whole program. About the only new feature that makes sense to me would be a checkbox option (on a per-notepad basis) to not display context parents, similar to the way the Phonebook works now. This would give Ecco true "hoisting" abilities, similar to what hardcore outliners like More and GrandView? used to have, and the overall impact on the program would be small. I'd also like to be able to have multiple calendars and phonebooks, but this can be simulated with filters already.

Chris

Python and Java are a bit slow, though, and the GTK widgets look funny under Windows. Do people here have experience with wxWidgets and C++, and could tell us how practical a solution it would be to write an open-source Ecco with those tools?

Fred.

I choose Java over Python. While I do like Python for it's very elegant syntax, Java has much more components available at the moment for building apps like Ecco. The way I see it, Python is currently geared more towards being a contender for web-based apps in general and PHP in particular. Java on the other hand is clearly aimed at building business-applications with fat-clients (if needed/wanted).

Java also has good object-relational mapping tools like Hibernate, that take a lot of coding out of the project and have a proven trackrecord for delivering very stable performance. In addition there are several Java-based embedded database-engines available as Open Source. IBM just released their flagship embedded java database Cloudscape as Open Source and HypersonicSQL? also has a very good trackrecord. These databases can run stand-alone on a networkserver for workgroup scenarios but they can be embedded into an application (they have a small installation footprint) so the stand-alone user dont have to install it seperately. They are SQL-complient and have a JDBC-driver available so data stored into these databases can be accesses by OpenOffice? without any additional coding (the OpenOffice? developers took care of that). This again takes another big part of coding OUT of the project.

Hans Peter.

Chris Thompson <thompson.chris@gmail.com> wrote:

   You want to clone Ecco's functionality, plus build a full-featured
   email client, plus add serious CRM capabilities... [...] Before you
   do, it might be worthwhile reconsidering whether or not to your
   efforts might be better spent towards reviving outlining integration
   in Chandler, or even adding outlining to Evolution.

Another alternative is to have a look at the project that intends to integrate PIM functionality into Thunderbird, instead of having it separated into a stand-alone application (Sunbird).

http://wiki.mozilla.org/index.php/Calendar:Lightning

Davor

It seems logical to look at existing projects instead of starting a new one. However, the problem is that all these projects (Sunbird, Evolution, Chandler, etc.) have been developed from a certain point of view. In the mentioned cases they all are e-mail centric and that in itself is a problem to implement the functionality like Ecco onto these programs. To have Ecco-like functionality combined with email functionality you must start the development based on this specific combination. Adding CRM-capabilities in a way that it fits seamlessly into the concept needs the same consideration.

I will try to make it a bit more clear for those interested:

Let's look at integration of email into the Ecco-model. When you start with an existing application like thunderbird for example, the application is handling it's data (emails) in a certain way. When that certain way was developed, nobody thought about outlining and cross-referencing through columns. When you want to add Ecco-functionality it will always exist BESIDES the native thunderbird data-handling stuff. So certain things will be very difficult or even impossible in that scenario.

On the other hand, if you develop an application like Ecco and implement email based on the Ecco(like) data-model then you can do with email all the things that you can currently do woth every other bit of information in Ecco. How about having emails show up in an outline based on filtering results. Or how about being able to group emails into different views the way that Ecco currently let us group anything else. It will make the standard folder-system of every other email client look prehistoric.

I would like to be able to have an outline for a project and have emails automatically (by filtering or scripting) show up in a specific part of this outline, preferably devided into sub-branches per sender. Imagine to have the Ecco-possibilities on top of your current email management. I don't see any of the other projects going this way. For Evolution and Thunderbird I think it is close to impossible because of the way these apps are designed from the start.

Hans Peter.

   One of my major frustrations is the difficulty of taking contact info
   out of an email vcard and entering into Ecco.  As an easy first step
   to help Thunderbird/Ecco? users, what about enabling direct capture of
   email address and vcard data from email into Ecco.  That would be a
   major step forward.

Is Ecco scriptable in any way? Is there some kind of API that external program scan use to add data to an Ecco file at least?

Davor

Yes, Ecco is quite scriptable. The scripting interface uses DDE, which is fairly old school, but it works well, and it's easy to wrap in a set of convenient functions in whatever language you want, since everything supports DDE. There's a Delphi library for accessing Ecco in the Files section of the Yahoo Group, and there might also be others. If you just want a convenient ActiveX?/COM Automation interface to Ecco, there's a commercial vendor (ivitar Software) who sells such a library for a reasonable price. The documentation for Ecco's scripting interface is in the TechInfo?.eco file in your Ecco program directory.

Be aware that the scripting interface has a minor Y2K bug. The "get all records changed since the last time I asked" function doesn't work properly if ran on an Ecco file which was first created after the year 2000. It doesn't break, but the performance is slower because it always returns all the records in your file. The workaround is to set your clock back to 1999 before creating any new Ecco files, or download the empty Ecco file in the files area created prior to 2000. Once a file is properly created, you never have to worry about this.

Chris

Wow, that sounds really interesting. I'm very tempted to try experimenting with integrating Ecco and T-bird, although now is such a busy time at work that it will have to wait for a while.

I have a question about your workaround on that Y2K bug with files created after 1999. If I wanted to recreate my current Ecco file as one older than 1999, what would be the best way without losing my filters, folders and everything else? It looks like Export-ing it, setting my clock back, starting a new file, and then Import-ing the data wouldn't quite do it.

Davor

from the Thunderbird plug-in section: With EVM, you can store your mails in a database in one or more categories. You can build categories by your own and rename them. And you may search for, and find, mails by attributes. http://evm.mozdev.org/

Perhaps this could help bring Thunderbird email into Ecco. Maybe we are closer than we thought...?

Thanks for that link. The EVM extension looks like it would be a great reference point for someone trying to build a Thunderbird extension for Ecco. (One could also access its underlying database and query it that way, if you wanted to.) I dabbled a bit with writing Firefox extensions a couple months ago, and because of the lack of tutorial-style documentation for specific XPCOM interfaces, it's almost always easiest to find an extension that does something like what you want to do, look at it, figure it out, then use that knowledge to implement similar functionality in your own extension. I'm sure the same applies to Thunderbird.

What would be really nice would be an example showing how to access Thunderbird's XPCOM interfaces from out-of-process (i.e. from a script or program running outside of Thunderbird, not as an extension). I was never able to track down an example that did this for Firefox's XPCOM interfaces, though I know it's possible. Someone on the Thunderbird newsgroups may be able to point you in the right direction here, if this is what you want to do.

Chris

I have not seen much activity about the source code, so I thought I would toss something out for discussion.

Since Ecco is built on Faircom's c-tree database engine, and since c- tree is not open source, we shall have to replace Ecco's c-tree infrastructure.

I can certainly help in this regard. Without having seen the sources, I can only make guesses about what would work best, but we may want to use SQLite (www.sqlite.org). Although Faircom's c-tree is more like BerkeleyDB?, an engine with more features may help Ecco advance along a roadmap. SQLite is portable, open-source, compact, scalable, simple to use, and has a non-viral license.

I have also worked with BerkeleyDB?, MySQL?, PostgreSQL?, various commercial RDBMS platforms, OLAP servers, XML, and various low-level algorithms.

Cheers !