Slashdot Mirror

← Back to Stories (view on slashdot.org)

News From The Evolution Front

Posted by timothy on from the stereo-vision-is-all-the-rage dept.

An anonymous reader writes "Sun's Java System Calendar Server connector (Hydrogen) for Evolution 1.4 on Solaris and Linux was GPL'ed today and is now available in GNOME CVS. This follows the recent GPLization of Novell's Ximian Connector (for Microsoft Exchange servers). In related news, the next major version of Evolution (version 2.0) is supposed to be released sometime during the next month, and beta testing have picked up pace. If you have some spare time, you can also give the Evolution 1.5.9 a spin. You can also use jhbuild to build Evolution from CVS (since the binaries are quite old by now). There is also a new project in GNOME CVS, called Evolution Brainread which adds a blog viewer to Evolution. It is not yet quite ready for production use, but looks quite good."

5 of 52 comments (clear)

  1. depends on Mono? by Euphonious+Coward · · Score: 4, Interesting

    Nat remarked in a recent interview that Evo 2 would depend on Mono. Did I understand correctly?

    1. Re:depends on Mono? by Jahf · · Score: 5, Informative

      My understanding is that Evolution 2.0 would -not- depend on Mono, since the goal is to revamp the client and make it stable first, but that versions beyond 2.0 would possibly begin to include Mono into the core and hence if you're planning on building a distro with Evo2 it makes sense to start getting Mono running and stable ASAP so that that is not a barrier.

      NOTE: I get this from an email from a Java Desktop System engineer who said he got word straight from Nat that Evo2 would not have Mono dependencies.

      GNOME will probably also be in much the same way ... 2.8 and maybe 3.0 will likely not see a core dependency on Mono but afterwards I expect that Novell will begin moving towards a Mono base for development for GNOME and Evolution (remember that as of GNOME 2.8, Evo2 and Evo Data Server become core GNOME components).

      As relates to Sun Java Desktop System (disclaimer: of which I work on in a tech marketing capacity) since obviously Sun is going to be much more interested in Java as a platform, not Mono (NOTE: I'm not saying Sun won't include a Mono platform in Java Desktop ... I can't say that since I don't know what the final answer will be on that). However, Java is becoming more viable for GNOME (and therefore Evo) development as well. My guess is were about to see Java vs. .NET in some form again. However, if Mono becomes a core of GNOME/Evo to where you can't function without it we will only have 2 choices ... include Mono or take tons of time to provide Java alternatives. I think both have advantages and disadvantages.

      --
      It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
    2. Re:depends on Mono? by Euphonious+Coward · · Score: 4, Interesting
      It's good news that Evo 2 won't depend on Mono.

      It would be hard to say whether GNOME coming to depend on Mono or on Java would be worse. Each outcome, on reflection, looks worse than the other. Sun and Microsoft both have submarine patents on the runtime techniques, and both are deeply hostile to Free Software: MS would like to kill it, while Sun hopes to "0wn" it. The only saving grace in Java's case is Gcj, which might be proof against patent risks. There's no equivalent for C#.

      Both are cargo-cult languages, with features shoveled in without understanding how they interact. (As a result, e.g., using exceptions in Java doesn't actually lead to simpler code.) We still have no other language as useful for serious application and library development as C++. It's a pity that the GNOME crew are so ridden with superstition by their exposure to early (and badly broken) MSVC++ as to be unable to perceive the merits of ISO standard C++. It's is free, legally safe, and (like Algol-60) "an improvement not just on its predecessors, but on its intended successors". Someday there will be a language that deserves to replace C++ for serious work, but it won't be Java or C#.

    3. Re:depends on Mono? by Jahf · · Score: 4, Informative

      What I am saying is the goal of Evo2 is to make architectural changes to the client (as in splitting out the Evo Data Server portion, improving the UI, etc) and make sure it is stable in that iteration before going to a new development technology.

      1.5.x is the unstable testing version for Evo2 ... the Evo developers want to get Evo2 stable in time for GNOME 2.8 core inclusion in a timely manner (originally the target was GNOME 2.6) and that means not doing a significant shift in the way Evolution is developed.

      If Evo2 were to ship with GNOME 2.8 -and- start using Mono as a core technology, Evo2 would either take a lot longer to release -or- it would be initially unstable :)

      Like I said in the parent, I haven't personally used 1.5.x so I can't vouch for the stability (though I definitely like the things I've read both on stability and features).

      As for the current version (1.4.x) being unstable ... in my experience that depends on what you are using it for. Fast connections to an IMAP server without utilizing Evo1.4 plugins seems to work great. Start using any of the connectors and/or start working from remote (and I do have a very good broadband connection) and, well, even though Evo1.4 is the default mail client for the product I work on I am currently using Mozilla Mail for production use and Evo1.4 only for testing features.

      --
      It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
  2. Checked exceptions catches a lot of bugs by lokedhs · · Score: 3, Insightful
    It's arguments like yours that caused MS to remove the checked exceptions in C#, and that is very bad.

    In almost all cases, maybe 95%, there is a real reason to catch a checked exception. Not catching the exception is an error, and should be flagged as such by the compiler.

    For example, in C after calling certain functions (IO functions for example) you must check the return code for errors and act on it. Too often have I seen people only checking the return code from the open() but not from the subequent read() for example. Having these methods throw a checked IOException is a very good things, because it makes you deal with the error.

    Just because handing errors is freaking boring doesn't mean you don't have to.

    Also, there are RuntimeExceptions which doesn't need to be caught.

    There is a very simple rule of thumb that should be used when deciding wether to use a checked exception or a RuntimeException: If the potential exception can be thrown from a perfectly bug-free program, then it should be checked. For example: A perfectly correct program without a single bug can still receieve an IOException when reading from a file, because its out of the applications control. Obviously this must be a checked exception.

    On the other hand, a NullPointerException is unchecked because it is possible to write the code in such a way that you are guaranteed that they are never thrown.

    Now, this rule does not always work perfectly and at times like that it can be a bit painful. For example, InputStream.read() is declared to throw IOException. However, this means that you need to deal with IOException even when reading from a ByteArrayInputStream. These cases doesn't come up that often (if it does to you, you really should think about the quality of the code you are writing) and in the case when it does, it can be wrapped in a simple:

    try {
    doSomething();
    }
    catch(IOException e) {
    assert false : e.getMessage();
    }
    Another annoying quirk is why Integer.parseInt() is declared to throw an unchecked NumberFormatException while NumberFormat.parse() is declared to throw the checked ParseException?