Calendar and other family time management features - how to start ?

[bulek]

Hi,

I've read this in other thread and would like to hear some more opinions on how to implement such features that are quite needed (at least in my case) to better manage family time (appointments,remainders,calendar,todo's....)...

there currently is no calendar for lmce, but i do plan to add a few things to the orbiter, this being one of them, eventually.

....

-Thom

Do you have any plans or ideas, what to use for backend support for calendar - maybe some lighter groupware... ?
Major advantage of such solution would be possibility to sync with outlook and mobile phones...  I'd like to try few options, I'm just curious what are your current plans on how to tackle this one on the backend side...

Currently Egroupware attracts my attention. Main advantage is possibility to sync data with mobile phones and outlook....Major disadvantage is that it is probably an overkill, also it has quite complicated web GUI.... I'd like to have something lighter, but haven't found anything usefull yet... Anyone has some proposition ?


Thanks in advance,

regards,

Bulek.

[tschak909]

the trick is to choose a system that is:

(1) Lightweight, few dependencies
(2) has an RPC interface that exposes the calendar data and commands to push data to and from the calendars

if we have to design something to that effect, then..cool..whatever. most of the larger groupware systems are very heavy, and would markedly increase dependencies.. and a lot of the smaller ones lack the RPC needed to present a proper orbiter interface....

so i guess, we write our own.

-Thom

[totallymaxed]

the trick is to choose a system that is:

(1) Lightweight, few dependencies
(2) has an RPC interface that exposes the calendar data and commands to push data to and from the calendars

if we have to design something to that effect, then..cool..whatever. most of the larger groupware systems are very heavy, and would markedly increase dependencies.. and a lot of the smaller ones lack the RPC needed to present a proper orbiter interface....

so i guess, we write our own.

-Thom

How about e-Groupware? http://www.egroupware.org/

It has an xml-rpc interface and has few dependencies... see http://www.egroupware.org/dependencies

Andrew

[bulek]

the trick is to choose a system that is:

(1) Lightweight, few dependencies
(2) has an RPC interface that exposes the calendar data and commands to push data to and from the calendars

if we have to design something to that effect, then..cool..whatever. most of the larger groupware systems are very heavy, and would markedly increase dependencies.. and a lot of the smaller ones lack the RPC needed to present a proper orbiter interface....

so i guess, we write our own.

-Thom

How about e-Groupware? http://www.egroupware.org/

It has an xml-rpc interface and has few dependencies... see http://www.egroupware.org/dependencies

Andrew

Hi,

I'm also leaning toward egroupware at the moment....

Particularly important is abitlity to sync with mobiles and outlook (at least in my case and thinking)....
http://www.egroupware.org/sync

Let me add another few interesting links I found on this matter :
http://www.cynthiaarmistead.com/groupware/index.shtml
http://lists.netisland.net/archives/plug/plug-2006-03/msg00036.html

This guy already tried few alternatives :
http://modernnomads.info/blogs/view_post.php?content_id=212

I've also spotted good opinions for Zimbra ....

http://mac.softpedia.com/progScreenshots/Zimbra-Collaboration-Suite-Screenshot-12739.html

Screenshots looks way better, it has soap interface (and I think sync feature also) and a lot of example scripts :
http://zimbra.svn.sourceforge.net/viewvc/zimbra/trunk/ZimbraServer/src/perl/soap/

HTH,

regards.

Bulek.

[tschak909]

honestly, i have serious problems bringing together all these different web UIs.

It's all duct tape. We need to unify the look of all the apps, web and orbiter, together!

-Thom

[bulek]

honestly, i have serious problems bringing together all these different web UIs.

It's all duct tape. We need to unify the look of all the apps, web and orbiter, together!

-Thom

I couldn't agree more. But this means a lot of work and it will take time to complete it...

But in the mean time, we can have a good backend with some sort of API interface and we can show info in limited way in Orbiters and for now use web interface. We can also make our own web interface via API - but till then we can use existing web UI, subset of features via Orbiter and sync feature with mobile phones and outlook...

So I guess we should consider those apps as backend engines with possibility to interact with them via API interfaces... LMCE is using this philosophy all over the system...

I guess what we need now is some possibility to show/interact with such data on Orbiter, create some standard way of presenting/storing such data and then let different plugins handle it. Since this is time non-critical task, using Ruby would be probably more widely accepted...

Regards,

Bulek.

[totallymaxed]

honestly, i have serious problems bringing together all these different web UIs.

It's all duct tape. We need to unify the look of all the apps, web and orbiter, together!

-Thom

I couldn't agree more. But this means a lot of work and it will take time to complete it...

But in the mean time, we can have a good backend with some sort of API interface and we can show info in limited way in Orbiters and for now use web interface. We can also make our own web interface via API - but till then we can use existing web UI, subset of features via Orbiter and sync feature with mobile phones and outlook...

So I guess we should consider those apps as backend engines with possibility to interact with them via API interfaces... LMCE is using this philosophy all over the system...

I guess what we need now is some possibility to show/interact with such data on Orbiter, create some standard way of presenting/storing such data and then let different plugins handle it. Since this is time non-critical task, using Ruby would be probably more widely accepted...

Regards,

Bulek.

I agree with both of you on this... Thom's right we ultimately need a single Web UI for all the of the services. But I agree that using what is available now in whatever e-Suite is chosen is ok as long as its a 'stepping stone' to a fully harmonised Web UI. The most important thing is to get the hooks in place in the orbiter to allow for the display/presentation of reminders/alerts/IM etc.

All the best

Andrew

[Marie.O]

So, we need a device that is capable of receiving messages from the dcerouter, and sending messages to the dcerouter.

This DCE device needs to be able to receive notification messages from the outside world and translate those messages to DCE messages. And this DCE device needs to receive DCE messages and send them to the outside, in whatever format necessary.

Doesn't that sound a bit like a GSD with the serial/IR part removed?

rgds
Oliver

[tschak909]

well basically...

what you have, is a back end that's exposed. With e-groupware, this is probably xml-rpc.

we have an xml-rpc provider device that runs on the core, that marshals requests to and from said backend.

then we have a plugin running on the router (Groupware plug-in?) .. that creates the data grid generators, and any event interceptors that we wish to catch events being emitted to the provider. The datagrid and event interceptors must be done inside a plugin because these functions need direct access to pointers to the relevant classes (Orbiter_Plugin, Datagrid_Plugin, etc.)

We then feed the appropriate datagrids, which we can then place on orbiter displays.

-Thom

[itspac]

http://www.opengroupware.org/en/applications/index.html

[totallymaxed]

http://www.opengroupware.org/en/applications/index.html

Well OpenGroupware seems to have an xml-rpc API so thats good. However it does not seem to have any specific Kubuntu support... I could be wrong about that though. I also could not find any information about its dependencies.

So all in all I guess OpenGroupware is a candidate too...

Andrew

[bulek]

http://www.opengroupware.org/en/applications/index.html

Well OpenGroupware seems to have an xml-rpc API so thats good. However it does not seem to have any specific Kubuntu support... I could be wrong about that though. I also could not find any information about its dependencies.

So all in all I guess OpenGroupware is a candidate too...

Andrew

I'll probably try Zimbra (cause of web interface) and Egroupware (cause it has nice sync mobile/outlook features). I'll report back...

For a start I'll try to prepare module in Perl that will report on upcoming and existing events in calendar... Anyone with similar plans...

Regards,

Bulek.

[chriss]

Hi Bulek,

I'm currently checking out Funambol (www.funambol.com/opensource) for my company. It provides good synchronization support (calendar, contacts, notes, emails...) between different devices, e.g. Outlook, Thunderbird/Lightning/Sunbird, mobile phones, PDAs etc. Funambol is no groupware but a pure SyncML synchronization server. If you have a nice groupware that does not provide satisfy with its synchronization feature Funambol can be the link to your home computer and CE devices. I think it would be cool to have such a sophisticated synchronization mechanism inside LMCE.

Regards,
Chriss

[totallymaxed]

http://www.opengroupware.org/en/applications/index.html

Well OpenGroupware seems to have an xml-rpc API so thats good. However it does not seem to have any specific Kubuntu support... I could be wrong about that though. I also could not find any information about its dependencies.

So all in all I guess OpenGroupware is a candidate too...

Andrew

I'll probably try Zimbra (cause of web interface) and Egroupware (cause it has nice sync mobile/outlook features). I'll report back...

For a start I'll try to prepare module in Perl that will report on upcoming and existing events in calendar... Anyone with similar plans...

Regards,

Bulek.

One of my team here reckons that Zimbra will prove very difficult to get working if you want to install it on the Core... due to a large amount of dependencies. It might prove easier if on a secondary box. Another problem he highlighted is the performance hit Zimbra may make on the Core... its written in Java and its recommended that you have at least 1gig of RAM just for Zimbra... of course the Core already had dozens of heavy weight processes running on it... so this may prove to be a real problem.

Andrew

[tschak909]

guys
guys
GUYS
GUYS!!!

STOP THINKING HUGE!

All of these systems you're proposing are downright humongous groupware systems intended for either departments or corporate use, they have no applicability in a home, and will become a user interface nightmare, at the very least, not counting dependency hell etc.

Before we think anything, we need to lay out how we want the user experience to be.

-Thom