Weekly Edition
Return to the Development page
| |||||||||||||
Pocock: Calendar and Contact data with free software in the Smartphone eraAt his blog, Daniel Pocock assesses the state of free software support for calendar and contact data on smartphones. Historically, he notes, a number of approaches were tried and failed to pick up significant traction, such as LDAP and SyncML. "The good news is, CardDAV and CalDAV are gaining traction, in no small part due to support from Apple and the highly proprietary iPhone. Some free software enthusiasts may find that surprising. It appears to be a strategic move from Apple, using open standards to compete with the dominance of Microsoft Exchange in large corporate networks." Despite the openness of the standards, however, Pocock goes on to detail a number of challenges to working with them in free software on a mobile phone. (Log in to post comments)
Pocock: Calendar and Contact data with free software in the Smartphone era Posted Sep 15, 2013 16:06 UTC (Sun) by obrakmann (subscriber, #38108) [Link]
Not sure why the author does not look at the various Kolab sync adapters in that article. Sure, they don't use Cal/CardDAV, but that makes them so much easier to set up. One only needs IMAP access, which most people probably already have, even if they are only using freemail services.
Also, I don't know any Kolab client that isn't open source.
Pocock: Calendar and Contact data with free software in the Smartphone era Posted Sep 15, 2013 21:36 UTC (Sun) by pboddie (guest, #50784) [Link]
I guess the CalDAV/CardDAV aspect is important when considering mobile clients and the standards most likely to be adopted by those and other clients. The IMAP approach is a nice idea, especially when contrasted against the weight and complexity of any WebDAV-based solution, but I suppose people don't always want to have to deal with IMAP, and being able to use Web infrastructure is arguably a lot more attractive than becoming comfortable with IMAP servers.
But yes, if people are already using IMAP, making better use of it as an event/contact store seems to make a fair amount of sense.
Pocock: Calendar and Contact data with free software in the Smartphone era Posted Sep 16, 2013 22:32 UTC (Mon) by sciurus (subscriber, #58832) [Link] The next release of Kolab (3.1) will expose its contact and calendar data via CalDAV and CardDAV. I think this is mainly important for people using OS X, who will now be able to use it's native calendar and contact apps with Kolab. For mobile devices, Kolab already implements ActiveSync, which iOS, Android, and Windows Phone all support.
Pocock: Calendar and Contact data with free software in the Smartphone era Posted Sep 17, 2013 15:06 UTC (Tue) by niner (subscriber, #26151) [Link]
It looks to me like Kolab is an all in one server. Sounds like much work to set up for just syncing between two clients. Also what if I don't want to change my IMAP server? dovecot is already working just fine.
Pocock: Calendar and Contact data with free software in the Smartphone era Posted Sep 17, 2013 17:50 UTC (Tue) by obrakmann (subscriber, #38108) [Link]
You don't need a Kolab server to sync contacts and calendars using a Kolab client. Any plain IMAP server will do. The only reason the sync providers use the name Kolab is because the data is stored in the Kolab file format.
Pocock: Calendar and Contact data with free software in the Smartphone era Posted Sep 18, 2013 9:50 UTC (Wed) by krake (subscriber, #55996) [Link]
Kolab is an orchestration of a set of services. One role is an IMAP server, by default Cyrus.
Other IMAP servers can be used as well, see http://kolab.org/blog/grote/2013/03/19/using-kolab-doveco... for an account of someone who uses Dovecot
Pocock: Calendar and Contact data with free software in the Smartphone era Posted Sep 15, 2013 17:50 UTC (Sun) by freetard (guest, #92836) [Link]
What about Windows clients?
Pocock: Calendar and Contact data with free software in the Smartphone era Posted Sep 15, 2013 22:43 UTC (Sun) by Seegras (subscriber, #20463) [Link]
Well, there's Mozilla Lighting for Windows too ;)
Pocock: Calendar and Contact data with free software in the Smartphone era Posted Sep 16, 2013 3:22 UTC (Mon) by freetard (guest, #92836) [Link]
The linked article described problems with Mozilla Lighting. I guess people will stick with Exchange/Outlook.
Pocock: Calendar and Contact data with free software in the Smartphone era Posted Sep 16, 2013 6:01 UTC (Mon) by nhippi (subscriber, #34640) [Link]
Pocock: Calendar and Contact data with free software in the Smartphone era Posted Sep 16, 2013 22:26 UTC (Mon) by sciurus (subscriber, #58832) [Link] The author is using DAViCal, but people may also want to check out Baikal. It's a lightweight CalDAV+CardDAV server written in PHP. It's easy to run on shared hosting since it can use SQLite or MySQL for storage.
Pocock: Calendar and Contact data with free software in the Smartphone era Posted Sep 16, 2013 22:51 UTC (Mon) by jonabbey (subscriber, #2736) [Link] I've been surprised not to see more coverage of Bedework when people talk about open source calendaring servers. It's certainly more heavy-weight than a lot of other stuff in this space, but they're also probably putting more development effort into their stuff than anyone else out there.
Pocock: Calendar and Contact data with free software in the Smartphone era Posted Sep 20, 2013 20:55 UTC (Fri) by NightMonkey (subscriber, #23051) [Link]
Ah, as soon as I saw it was written in Java, my sysadmin heart sank. When will folks learn that all that indirection that makes it "so great" to code in has to be unwound somewhere? That somewhere, with Java, is in Operations, and most of the time, after being buried in indecipherable backtraces, all we can do is restart the damned thing. :/
Pocock: Calendar and Contact data with free software in the Smartphone era Posted Sep 20, 2013 21:01 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
As soon as I saw someone whining about Java, my heart sank. When folks will learn that all that whining about "indirection" or "memory efficiency" that makes it "so awful" is simply laughable, while they themselves don't write any significant amount of application code.
Pocock: Calendar and Contact data with free software in the Smartphone era Posted Sep 20, 2013 21:48 UTC (Fri) by NightMonkey (subscriber, #23051) [Link]
Wow, that was mean.
Pocock: Calendar and Contact data with free software in the Smartphone era Posted Sep 21, 2013 4:10 UTC (Sat) by ploxiln (subscriber, #58395) [Link]
As off-topic as this thread is getting, I am quite sympathetic with NightMonkey's opinion of java applications. It's not about the language itself, it's about the culture of absurdly complicated solutions.
I program quite a bit of python and C (and Go and tcl and bash), and also maintain parts of a server deployment system, and speak from experience of deploying Jenkins as well as a some custom internal applications written by someone who left the company, and I can provide specific criticisms.
Memory usage is hard to guage. We have graphs of system memory use, which we typically use to see if memory use is growing, either leaking or just growing along with load on the application, to guage how much memory the system really needs etc. Java has a tendency to use whatever is set for its max heap size. It dips down when it garbage collects, but for efficiency it hovers around the limit. We also have munin graphs of jvm heap, with quantities of "eden" "survivor" "old_used" and "permanent" memory, but that still doesn't give a clear picture of how much memory the thing really needs. We're not java enthusiasts so we don't look any further than that. Instead, we find out when the app crashes with "HeapAllocationError" or something. Virtually all other languages compile to something that just keeps allocating system memory when it needs more and gives it up when it's done (with maybe a 50% overhead), and can be contained with "ulimit -v" or a script that watches its RSS and kills it. But with java apps we just don't know until it crashes, which is great because java apps tend to use the most memory.
Backtraces are almost always over 70 function calls deep, in these typical style java applications. It's great how java will even elide the middle 50 of them for you with a (...), because no one is going to bother to make sense of that insane call path with function and object names that seem to all be permutations of the same base words (doConnection, getConnectionHandler, handleConnection, connectHandler, handlerConnectAction), dipping into various versions of various dependencies that are embedded in the jar of the application itself. We generally fix these problems by rewriting in some other language.
Java apps tend to be generally distributed and deployed as complicated monolithic things. We have a mechanism that installs and updates binaries and libraries, and a separate scheme to export and manage configurations for different servers, and we like to make sure application data on disk is in a separately managed and backed-up location. Applications like jenkins practically force all 3 to be in the same place. The only useful configuration option is JENKINS_HOME, it'll unzip the contents of its WAR and plugins into there and put its xml configs in there and put the build and test results in there...
Again, the problem tends to be correlation - huge and overly complicated software overwhelmingly tends to be written in java, and vice-versa, it's just the culture or something. Eclipse, other stuff I can't remember... it's like my aversion to Microsoft stuff, it's not irrational, I just moved on from remembering all the specific ways it's terrible many years ago.
Pocock: Calendar and Contact data with free software in the Smartphone era Posted Sep 21, 2013 23:06 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Complex Python/Perl/whatever applications are just as hard to deploy.
And Java apps generally have advantage of being self-contained. JVM indeed suffers quite a bit from nice-operating-system-but-misses-a-good-language syndrome, but it's about the only game in the town if you want a portable application in a safe statically-typed language.
Pocock: Calendar and Contact data with free software in the Smartphone era Posted Sep 24, 2013 20:07 UTC (Tue) by jwakely (subscriber, #60262) [Link]
The JVM has several good languages, but Java isn't one of them.
|
|||||||||||||