Announcing the OpenGroupware Coils project...

This message is the official public announcement of the OpenGroupware
Coils project.

**** ANNOUNCEMENT ****
OpenGroupware Coils <http://sourceforge.net/projects/coils/> is a port
of the OpenGroupware collaboration platform from SOPE & Objective-C to
Python 2.6.  It is intended to be backwards compatible and can be
installed in parallel with your existing OpenGroupware Obj-C services
stack.  OpenGroupware Coils will read you OpenGroupware Obj-C
configuration files, connect to your OpenGroupware Obj-C database, and
perform updates in a manner compatible with OpenGroupware Obj-C.
OpenGroupware Coils will maintain parallel compatibility until such time
as it reaches operational feature parity.  This is an *alpha* release of
OpenGroupware Coils and is (a) not feature complete and (b) under heavy
development.  However to commitment to parallel compatibility until
feature-parity ensures that moving between development versions will the
painless;  and you can continue to use your existing OpenGroupware
application stack.

What works today?
 1.) Reading and management of NextStep/OpenStep configuration files.
Coils can both read an write the same plist files for user defaults and
the NSGlobalDomain plist for configuration information.  So installing
OpenGroupware Coils is a zero-config process.  Although there very well
may be items you want to tweak.  Every effort is made to re-use existing
OpenGroupware defaults - which are documented in WMOGAG
<http://docs.opengroupware.org/Members/whitemice/wmogag/file_view>
 2.) The XML-RPC proxy will intercept XML-RPC calls to OpenGroupware
Obj-C's ZideStore service.  It provides retry, so if the call to
ZideStore fails [due to process restart, etc...] the call is
automatically retried.   It can also process specific API calls in Coils
while relaying others to ZideStore's zOGI bundle.  This allows a gradual
migration from ZideStore's zOGI implementation to Coil's implementation
transparent to applications.  By default the Coil's zOGI only processes
zogi.getLoginAccount calls.  This offloads most of the authentication
related calls from ZideStore to Coils.
 3.) The GroupDAV/WebDAV presentation of the contacts available to a
client has been tested in Novell Evolution successfully.  Coils has been
architected to make the presentation of large collections as efficient
as possible.  Testing is performed using an addressbook containing
22,000 contacts.  Write support is in the early stages of development.
Coils uses the Python module vobject
<http://vobject.skyhouseconsulting.com/> to process vCard data.
 3.1.) Contacts can be retrieved from the server as vCards or presented
in XML, JSON, or YAML.  Whatever is easiest for your client application
to process.
 3.2.) A special URL provides a JSON feed of contacts or users
(accounts) with upcoming birthdays.
 4.) Read support should for for CalDAV clients.  Collects are presented
that provide either the user's personal calendar or a user's Overview
calendar as determined by their panel.
 5.) Most zOGI getObject(...) operations are functional.
 6.) A large portion of the require Logic (commands) have been
implemented.  Access control has also been implemented.  Access control
in Coils offers features in addition to the OpenGroupware Obj-C services
including proxy user and negative ACLs.
 7.) The OpenGroupware Integration Engine (OIE), which not complete, is
operational and has reached a useful level of utility.  OIE provides a
workflow and Business Process Modeling engine that tightly integrates
with OpenGroupware's more traditional groupware facilities.  OIE
currently manages workflows described using BPML 1.1.  
 7.1.) Routes can be created and modified, and processes initiated and
monitored via the WebDAV presentation;  the entire workflow system can
be controlled via GNOME's Nautilus file manager and possibly other
WebDAV clients [only Nautilus/GVFS have currently been tested].  
 7.2.) OIE can perform operations with external SQL databases [tested
with IBM Informix/DB2], search LDAP DSAs [search results are
XML/DSMLv1], manipulate XML (perform XPath assignments and XSLT
transformations), convert JSON data into XML, retrieve OpenGroupware
objects as XML (such as Contacts, Enterprises, etc...), send SMTP mail
(including attachemnts), and perform various string operations and
regular expression matches.
 7.3.) OIE contains an extensible method for dealing with file formats
such as fixed record length text files, XLS, and DIF files.  File
formats can be create and defined [as YAML text] via the WebDAV layer
using a text editor such as GNOME's gedit.  File format definitions
allow OIE to read or create formatted files, such as XLS documents.
 7.4.) OIE processes can "park".  Allowing processing to stop (actually
shutting down the worker on the server) awaiting additional data or user
response,  for example, from an e-mail produced by the OIE workflow.  In
future versions OIE's processing will be integrated further with
groupware functions allowing workflows to be initiated via task
creation/completion, entity modification, etc...   
  8.) OpenGroupware Coils provides the concept of "Content Plugins".
This implements the functionality intended for the ZideStore zOGI bundle
(pluginData entity is defined for the zOGI specification:
<http://code.google.com/p/zogi/wiki/PluginData>) but deemed unrealistic
to implement in the existing Objective-C environment.  Content Plugins
allow additional information from external services (such as an ERP
system) to be gathered by OpenGroupware Coils and delivered to clients
with related entities.  For example, when an Enterprise entity is
retrieved by a zOGI call sales and related information can be added by a
custom ContentPlugin to the data that is returned to the client.
Unwitting clients can simply ignore the additional information, but
custom interfaces such as a CRM system can present the information to
use user without themselves having to contain logic to gather the
information from ERP or requiring permissions to access the ERP.  Data
made available to OpenGroupware via Content Plugins is also
automatically available to OpenGroupware Integration Engine workflows.
So you can code your connectors once and use that data from everywhere
that you can access your OpenGroupware server via HTTP.  A developer
only needs to inherit the ContentPlugin class and their content plugin
will automatically be loaded and used by OpenGroupware Coils.  An
example ContentPlugin that provides integration with Twitter has already
been implemented;  this plugin automatically includes a contact's
Twitter timeline with the contact's data.
<http://coils.hg.sourceforge.net/hgweb/coils/coils/file/db62d0ee9f9b/src/coils/logic/twitter/content_plugin.py>
 
Architecure:
  OpenGroupware Coils is similair in many respects to OpenGroupware
Obj-C architecturally.  Both use a Logic layer where operations are
performed using Command pattern objects.  Both divide the presentation,
operational (Logic), and model into discrete layers.  
  However OpenGroupware Coils is implemented as a component oriented
service as it is intended to provide services in addition to web
services and to really less of external OS components [such as cron].
OpenGroupware is comprised of a collection of services - one of which
provides the HTTP services - that communicate via AMQ
<http://www.amqp.org/confluence/display/AMQP/> using an AMQ server such
as RabbitMQ <http://www.rabbitmq.com/>.  AMQ provides flexible, fast,
and *reliable* messaging between components.  [This design decision was
made only after it was clearly demonstrated that RabbitMQ is readily
available for all mainstream LINUX distributions and is *VERY* simple to
install and configure - in fact, you can get Coils up and running with
RabbitMQ with *zero* MQ configuration].  One exciting possibility AMQ
provides is for future versions of OpenGroupware Coils to distribute
services across multiple hosts or multiple networks.
  Component services include HTTP services, the OpenGroupware
Integration Engine, maintenance of the Contact vCard cache, and
appointment notification.  Implementing addition services is very simple
as all the AMQ plumbing is abstracted into the Service class.  All the
developer needs to do is inherit the coils.core.Service class and
implement a few methods and the service will automatically be started
with OpenGroupware Coils and connected to the messaging service.  For an
example of how, almost trivial, it is to implement an OpenGroupware
Coils service take a look at Coils "clock" service
<http://coils.hg.sourceforge.net/hgweb/coils/coils/file/db62d0ee9f9b/src/coils/logic/pubsub/clock.py> which provides a clock service to which other services can subscribe to.
  
How can I contribute?
  All contributions and comments are welcome.  
  Non-developers can help with testing or helping to maintain the wiki.
The project also needs web-desginers and artists.
  For developers source code is managed in a Mercurial
<http://mercurial.selenic.com/> repository on SourceForge.  Mercurial is
a modern distributed source code management system, which unlike CVS and
subversion, makes managing branches and commit access a very open and
natural process.  To check out the source code go to
<http://sourceforge.net/projects/coils/develop>.  <Monodevelop
http://monodevelop.com/> solution and project files are included in the
source; so if you have that excellent, free, and multiplatform IDE
available browsing the OpenGroupware Coils source is a snap.  But use of
Monodevelop, or any IDE, is not required to contribute code to the
OpenGroupware Coils <http://sourceforge.net/projects/coils/> project.
The excellent TortoiseHg <http://tortoisehg.bitbucket.org/> tools for
working with Mercurial are also recommended - but you can do everything
via the Mercurial hg command line utility.  Every kind of work is
available within the OpenGroupware Coils project:  if you want to work
with OIE to process XML and implement workflows, if you want to work on
HTTP protocols like WebDAV/GroupDAV/CalDAV/RSS there are jobs for you,
if you want to do database oriented work via the amazing SQLalchemy ORM
<http://www.sqlalchemy.org/>, or get into the nut-n-bolts of AMQP...
just check out the code and dig in.
  
For communication the OpenGroupware Coils project has two mailing lists:

coils-devel for discussion of the development of the OpenGroupware Coils
project;  technical stuff.
<https://lists.sourceforge.net/lists/listinfo/coils-devel>

coils-project for discussion of the project itself including website,
coordination, promotion, etc..
<https://lists.sourceforge.net/lists/listinfo/coils-project>

OpenGroupware Coils does not *yet* have a "coils-users" yet!  This is an
*alpha* release.  A "coils-user" list will be created with the project
deliverys a 1.0 download.   The project is currently looking for
developers and other contributors.  Not that OpenGroupware Coils isn't
already very usefule - it is! - but the project wants to be very clear
about its current state and not over-sell.

Links:
* Provisioning a CentOS5 host for OpenGroupware Coils
<https://sourceforge.net/apps/trac/coils/wiki/ProvisioningCentOS5>
* Installing OpenGroupware Coils
<https://sourceforge.net/apps/trac/coils/wiki/Installation>

  

-- 
OpenGroupware.org Users
[email protected]
http://mail.opengroupware.org/mailman/listinfo/users