[OGo-Discuss] Re: Some impressions and comments about OGo

[Adam Tauno Williams]

> > VALID - 
> > (1) The OGo packaging is rough and some packages don't enforce their own
> > prerequisites / dependencies.<snip>
>   Suggested fixes for the Debian packaging :
> 1)  In Debian Etch the Apache and Postgres virtual packages will install
> legacy versions by default (to enable graceful upgrade from Debian Woody)
> unless the current Apache and Postgres packages are already installed.
> OGo depends on these virtual packages.  The Debian OGo packages should
> warn about this so the user can abort the install and pre-install Apache2
> and Postgres 8.1 if desired.  There may be similar issues with
> libapache-mod-ngobjweb and libapache2-mod-ngobjweb.

Please check if there are open bugs for these issues, if not create
them.  I don't maintain Debian packages,  but Frank might fix them.

> 2)  The rewrite and include modules need to be enabled in Apache.  This
> MAY happen for Apache (don't know), but it certainly doesn't for Apache2.

Works on SuSE;  same as above.

> 3)  OGo should be enabled in the appropriate runlevels (at the users
> discretion).
>   Even if this is too much trouble, a README.Debian text file in
> /usr/share/doc/opengroupware (as per Debian tradition) explaining these
> issues would be appreciated.  Would have saved me quite a bit of time.

Seems a good idea;  file an enhancement request.

> > INVALID -
> > (1) OGo is a complex package,  people trying to install it without
> > **FIRST** reading the documentation should expect to have problems.
> > Nobody whips out an M$-Exchange CD pops it in the drive,  double clicks
> > install.exe, and then charges through the installing merrily clicking
> > random options.
>   Perhaps I'm just weird, but this is exactly how I learn...  

That is OK,  but then you also can't complain when it blows up. :)

> > Script magic can only
> > do so much to provide that - administrators should *EXPECT* to have
> > to setup these services.  If the current configuration differs from the
> > default or the distribution has done something torturous in packaging
> > the service there isn't any solution except reading the documentation
> > and setting up the service appropriately.  How to setup the services
> > manually is very specifically described in WMOGAG.
>   Many IT people are LAZY (not a bad thing) and/or have limited time.
> Making it easier to get a working (though untuned) config is a goal worth
> achieving IMHO.  

Of course, no argueing that.  Specific issues, like above, are useful.

> (The moans from the Sunbird Devel list asking for
> "someone else" to set up an OGo test server helped me understand this).
>   Surely a script automating OGo + Postfix + CyrusIMAP isn't a bad thing.

I think what a good distribution provides for Postfix & Cyrus should
work out-of-the box with OGo.

> I would be open to donating mine to the deb package.  Such things go in
> /usr/share/doc/opengroupware.org/examples as per Debian tradition. I'm
> only a novice scripter, but I guess something is better than nothing.
> Dire warnings for end users might be appropriate however.

At least upload anything you create to the docs plone.

>   I also plan to write another few scripts for the CTI stuff, Funambol and
> perhaps SpamAssassin/Amavis/ClamAV once I can actually make it all
> work manually.

Wonderful.

> >>/ I understand CalDAV is horribly complex, but the 
> />>/ first server to connect to a CalDAV/GroupDAV client reliably will 
> />>/ collect a HUGE number of users. 
> />
> > Agree.  But that won't happen magickally, and OGo is an Open Source
> > project....  
>   I'm no developer, 

Neither am I. :)

> but I've emailed the Sunbird list and have spoken to
> Bruno Browning (the Sunbird CalDAV guy).  It seems that noone from their
> side is interested in implementing GroupDAV as CalDAV is the priority
> right now.  He suggested either making OpenGroupware CalDAV compliant
> (which he understood would be a big task), or implementing a GroupDAV
> plugin for Sunbird.  I'm beginning to understand that neither of these
> things will probably happen in the near future, and I don't have the
> skills to do anything about that problem myself.
> >>/  GroupDAV probably won't be implemented 
> />>/ on a client before CalDAV is, so if OpenGroupware waits for a GroupDAV 
> > You are implying that you found CalDAV/GroupDAV not to work?
>   I've tried Sunbird, Mulberry and Chandler...  Sunbird was most
> acceptable, but still had issues with alarm notifications creating
> duplicate events.  I found a patch for Sunbird 0.5, but then I discovered
> another bug quite quickly, and from experience and discussions I now
> know that Sunbird is becoming less likely to work correctly against OGo

I only find one CalDAV issue in bugzilla.
http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1876
If there is an additional issue it needs to get reported.   These may or
may not be difficult to fix.  

As I poke around inside ZideStore I waffle between thinking it is either
really impressive or a labyrinthine train wreck.  Since it doesn't seem
to be getter any better qualified love I might take a look over the
holidays and see if I can figure anything out.   But most of my focus is
currently on zOGI & Consonance,  which is working pretty well these days
- after only three years of floundering about.  :)  I'm optimistic for
something generally useful in Q1 of 2008.

> > No, GroupDAV is not a subset of CalDAV.   CalDAV is specific to
> > calendering.  GroupDAV provides for contact information.
>   It was my understanding that both provide similar features, but GroupDAV
> was created as a subset of the CalDAV spec because of the complexity of
> CalDAV, 

That is part of it,  in addition CalDAV doesn't solve the issue of the
address book.

> and the fear that CalDAV would become another IMAP (ie. a complex
> spec with many slightly incompatible implementations).  Perhaps I got the
> wrong impression?

CalDAV is complex,  but my understanding isn't that that was the primary
motivation behind GroupDAV.  There are some CalDAV haters on the lists
that certainly promote that notion.
-- 
          Consonance: an Open Source .NET OpenGroupware client.
  http://code.google.com/p/consonance/ - Searching for a bored Cairo# hacker.
   Contact:awilliam@whitemiceconsulting.com   http://www.opengroupware.org