Bongo - New pages [en]

Development/Format/JEvent

Alexhudson — Sat, 26 Jun 2010 14:15:16 GMT

Summary: New page: == jEvent / jTodo format == Calendars within Bongo are stored as collections, with the individual events being documents within the collection. Relevant attributes of an event are attache...

== jEvent / jTodo format ==

Calendars within Bongo are stored as collections, with the individual events being documents within the collection. Relevant attributes of an event are attached as properties on the document for the purposes of searching.

jEvent / jTodo format is loosely based on [http://www.ietf.org/rfc/rfc2445.txt iCal / RFC 2445], representing the same data but within a UTF-8 JSON structure.

=== Example representation ===

There are a couple of examples given in the RFC. One of the VEVENTS stripped from a calendar is this one:

<pre>
BEGIN:VEVENT
DTSTAMP:19970324T1200Z
SEQUENCE:0
UID:uid3@host1.com
ORGANIZER:MAILTO:jdoe@host1.com
ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host1.com
DTSTART:19970324T123000Z
DTEND:19970324T210000Z
CATEGORIES:MEETING,PROJECT
CLASS:PUBLIC
SUMMARY:Calendaring Interoperability Planning Meeting
DESCRIPTION:Discuss how we can test c&s interoperability\n
using iCalendar and other IETF standards.
LOCATION:LDB Lobby
ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/
conf/bkgrnd.ps
END:VEVENT
</pre>

This would be transformed into jEvent in the following manner:

<pre>
{
'jEvent' : 2.0,
'dateStamp' : '1997-03-24 12:00',
'sequence' : 0,
'uid' : 'uid3@host1.com',
'organizer' : 'mailto:jdoe@host1.com',
'attendees' : [
{
'rsvp' : 'true',
'mailto' : 'jsmith@host1.com'
}
],
'dateStart' : '1997-03-24 12:30',
'dateEnd' : '1997-03-24 21:00',
'categories' : ['meeting','project'],
'class' : 'public',
'summary' : 'Calendaring Interoperability Planning Meeting',
'description' : 'Discuss how we can test c&s interoperability using iCalendar and other IETF standards.',
'location' : 'LDB Lobby',
'attachments' : [
{
'format' : 'application/postscript',
'uri' : 'ftp://xyzCorp.com/pub/conf/bkgrnd.ps'
}
]
}
</pre>

Development/Format/JCard

Alexhudson — Sat, 26 Jun 2010 13:39:49 GMT

Summary: /* jCard Format */

== jCard Format ==

Contacts are stored within Bongo as individual documents, one contact per document. Relevant attributes for searching are brought out of the document as attributes for searching.

jCard is a JSON format based roughly on [http://tools.ietf.org/html/rfc2426 vCard aka RFC 2426]. The same attributes are used, albeit with more friendly names, and where-ever possible the data is decently structured. We're also following the work on the [http://tools.ietf.org/wg/vcarddav/draft-ietf-vcarddav-vcardrev/ update RFCs] as they are published.

Oddly, although RFC 2426 requires that FN, N and VERSION attributes MUST be present, they're not in the examples. However, for our purposes, we will specify that the must be present.

The version attribute will attempt to follow vCard. However, we will adjust as necessary to ensure forward compatibility: jCard 3.0 apps must be able to deal with jCard 3.1+ formats without breakage, although they may reject 4.0+.

In order to achieve that, we may only extend the JSON structure in certain ways.

=== Empty example ===

A very basic JCard as stored:

{"jCard":3,"fullName":"Test contact",
"name":{"familyName":[],"givenName":[],"additionalNames":[],
"prefix":[],"suffix":[]},"email":[{"address":"test@example.com",
"type":["internet"]}]}

=== Example representation ===

The RFC for vCard gives the following contact for an author:

<pre>
BEGIN:vCard
VERSION:3.0
FN:Frank Dawson
ORG:Lotus Development Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive
;Raleigh;NC;27613-3502;U.S.A.
TEL;TYPE=VOICE,MSG,WORK:+1-919-676-9515
TEL;TYPE=FAX,WORK:+1-919-676-9564
EMAIL;TYPE=INTERNET,PREF:Frank_Dawson@Lotus.com
EMAIL;TYPE=INTERNET:fdawson@earthlink.net
URL:http://home.earthlink.net/~fdawson
END:vCard
</pre>

This is expressed in jCard as:

<pre>
{
'jCard': 3.0,
'fullName' : 'Frank Dawson',
'organisation' : 'Lotus Development Corporation',
'addresses' : [
{
'type' : ['work', 'postal', 'parcel'],
'pobox' : '', 'extended' : '',
'street' : '6544 Battleford Drive',
'locality' : 'Raleigh',
'region' : 'NC',
'postcode' : '27613-3502',
'country' : 'U.S.A'
}
],
'telecoms' : [
{
'type' : ['voice', 'msg', 'work'],
'number' : '+1-919-676-9515'
},
{
'type' : ['fax', 'work'],
'number' : ':+1-919-676-9564'
}
],
'email' : [
{
'type' : ['internet', 'preferred'],
'address' : 'Frank_Dawson@Lotus.com'
},
{
'type' : ['internet'],
'address' : 'fdawson@earthlink.net'
}
],
'url' : [
{
'type' : ['personal'],
'href' : 'http://home.earthlink.net/~fdawson'
}
]
}
</pre>

Clearly this is a fair bit more verbose - mostly due to breaking out the address into a named structure rather than relying on position in array - but is more straightforward to use and parse.

Guides/Secure Authentication

Steve-o — Wed, 02 Jun 2010 17:37:38 GMT

Summary: /* openSSL Commands and Utilities */

= Secure Authentication =

== Terminology ==

* Public Key Encryption: Secure data transport utilizing public and private keys.

* Private Key: Decrypts. Contains the public key data, First step before a certificate or certificate request is generated. File.

* Public Key: Encrypts. Derived from the private key. Generally does not need to be generated separately. File.

* Certificate Authority: A trusted third-party entity that issues and/or revokes digital certificates.

*Root Certificate Authority: The top of a chain of certificate authorities. A trusted third-party entity that issues and/or revokes digital certificates.

* Sub-CA Certificate Authority: A child certificate authority created by a parent certificate authority. A trusted third-party entity that issues and/or revokes digital certificates.

* Root CA Certificate: A digital certificate granted to one certification authority (CA) by another certification authority. The root ca certificate will always be self-signed.

* CA Certificate: A digital certificate granted to one certification authority (CA) by another certification authority.

* Certificate: Certificate which has been authorized. Should contain the public key. Data may be encoded (pkcs7 or pkcs12, etc.). File.

* Certificate Signing Request (CSR): A request for certificate. Certificate authority signs the request and hands it back as authentic certificate. File.

== openSSL Commands and Utilities ==

Generate Private Key (RSA ):
<pre>$ openssl genrsa -out <filename> 2048</pre>

Generate Self-Signed Certificate From Private Key:
<pre>$ openssl req -new -x509 -days 365 -key <filename> -out <filename></pre>

Generate Private Key and Self-Signed Certificate:
<pre>$ openssl req -new -x509 -days 365 -nodes -keyout <filename> -out <filename></pre>

Generate Certificate Signing Request From Private Key:
<pre>$ openssl req -new -key <filename> -out <filename></pre>

Generate Private Key and Certificate Signing Request:
<pre>$ openssl req -new -nodes -keyout <filename> -out <filename></pre>

Generate Signed Certificate From Signing Request:
<pre>$ openssl x509 -req -days 365 -CA <filename> -CAkey <filename> -CAcreateserial -in <filename> -out <filename></pre>

View Details of Certificate:
<pre>$ openssl x509 -text -in <filename></pre>

== Bongo ==

=== Self-signed certificates ===

===== Prerequisite =====

* openSSL

The following example will generate 2 files, a cert file (-out) and a key file (-keyout) valid for 365 days:

<pre>$ openssl req -new -x509 -days 365 -nodes -keyout <filename> -out <filename></pre>

==== Interactive Q/A ====

The process of generating self-signed certificates leads you through a series of questions. The "Common Name" will be of most importance; it represents the host you are associating with.

===== FQDN example answers: =====

* Country Name: <US>
* State or Province Name: <Utah>
* Locality Name: <Springville>
* Organization Name: <Unified Functions>
* Organizational Unit Name: <IT>
* Common Name: <www.unifiedfunctions.com>
* Email Address: <admin@unifiedfunctions.com>

===== Wildcard example answers: =====

* Country Name: <US>
* State or Province Name: <Utah>
* Locality Name: <Springville>
* Organization Name: <Unified Functions>
* Organizational Unit Name: <IT>
* Common Name: <*.unifiedfunctions.com>
* Email Address: <admin@unifiedfunctions.com>

=== For Bongo ===

Bongo looks for the following files in the specified location. To replace the default certs, either replace the files with your own (retaining the same file names) or replace the contents of each file.

* replace contents of <install location>/var/bongo/dbf/osslcert.pem with the generated cert

*replace contents of <install location>/var/bongo/dbf/osslpriv.pem with the generated key

== Mail Clients ==

=== Thunderbird ===

I am not sure yet if Thunderbird 3 likes wildcard certs!

Releases/0.6.0

Alexhudson — Sun, 23 Aug 2009 14:17:30 GMT

Summary: /* Source installation */

= Bongo 0.6.0 Release notes =

<div class="warning-alpha" style="margin-top: 15px;">
Bongo is currently alpha-quality software. It is under active development and is not yet ready for production servers.

However, we encourage you to try it out in a test environment and let us know what you think!</div>

== About Bongo ==

Bongo is a project to create fun and simple mail & calendaring software. As well as providing a well-featured but extensible set of server software, it also comes with a user-friendly web interface.

Although Bongo is a young project, the software itself has a long pedigree going back to commercial products many years old. The core code isn't new, but the ideas we have and the direction we're taking are: we aim to provide a compelling alternative to other systems out there, not to compete directly with them.

We have a roadmap laid out to our 1.0 release, which we hope will appeal primarily to people who are interested in features which make email and calendars more useful, rather than those interested in "groupware" or "enterprise communication platforms". We're particularly aiming 1.0 at power home users, small organisations/businesses, and people providing mail services for third parties.

== What's In This Release? ==

This is the sixth release on the Bongo roadmap. As a source-only release, it is intended only for developers and advanced users who understand they will probably experience bugs and/or rough edges. This is also a server-only release: the web UI is known to have serious faults and isn't included.

However, we do intend that this release be usable for those brave users willing to try it: our previous releases, M4 and M5, have been used successfully by a number of people and has proved to be relatively stable.

== What's New? ==

Compared to 0.5, most of the changes will mainly interest developers. We have reworked the build system so that it is faster and easier to use, the libraries Bongo uses have been simplified and "imported" code has been removed, and various compiler warnings and errors have been found and fixed.

== Download and installation ==

With this release, we are making both source and binaries available. However, as the binaries are quite "new" we are still labelling this a source-only release. Please try the binaries first if you are able, and report any problems.

=== Binary installation ===

As mention above the binary creation is still in the infant stage so there are bound to be issues that we highlight. However we have been able to get the following distributions compiled.

[[Installation/Fedora | Fedora 11]]

[[Installation/RHEL | CentOS / RHEL]]

[[Installation/Suse | SUSE]]

Please install and test to let us know if there are any issues.

=== Source installation ===

You can download the 0.6 release from the GNA download page:

http://download.gna.org/bongo/release/bongo-0.6.1.tar.bz2

As a quick start, you once you've downloaded the release, you then:

tar -jxf bongo-0.6.1.tar.bz2
cd bongo-0.6.1
mkdir build
cd build
cmake ../ -DCMAKE_INSTALL_PREFIX=/usr/local/bongo -DBONGO_USER=bongo
make
(as root from here)
make install
cd /usr/local/bongo
./sbin/bongo-config install

We have instructions for compilation in our [[Installation/Source | source guide]] - you will need to fulfill various dependencies, but they are mostly pretty simple.

After you have compiled and installed, you can then set about [[Configuration/Bongo | configuring Bongo]].

Binary packages of Bongo are also being made available on an ongoing basis, but remember that this is still software under development.

== Upgrading ==

The upgrade should be relatively simple, and it should be possible to install 0.6 "over" an existing 0.4 or 0.5 installation and have it continue to work in the same manner. However, you should backup your data before attempting this.

To backup mail boxes, use a command such as:

bongo-storetool -u <user> -p <password> -h <bongo IP> sb

Leave out the host option if you are on the localhost. This will create a file called <user>.backup, which can then be restored with:

bongo-storetool -u <user> -p <password> sr <user to restore> [<backup file>]

See the bongo-storetool help for further options to store-backup (sb) and store-restore (sr). In particular, you only need to specific the backup file if the username has changed.

Having used storetool to back up the system, you could then install over the existing installation or do a clean installation. If you prefer the clean route, you will need to re-create your users and domains configuration after installation, then you can restore your mailboxes.

=== A 'semi-clean' install ===

If you have an existing 0.4/0.5 installation, you can follow this method to do a "semi-clean" install. Essentially, we move the old installation out of the way, install the new one, and add back in the various configuration files. You may need to change the file paths to suit your local installation.

<pre>
$ mv /usr/local/bongo /usr/local/bongo-old
$ sudo make install
$ sudo rsync -av /usr/local/bongo-old/var/ /usr/local/bongo/var/
</pre>

You should then be ready to rock with all your old data still there.

== Known Issues ==

You may want to review the project bugs page to see a complete list of those issues discovered. At the time of release, the following bugs are known:

* (major) the Dragonfly web UI is unusable for most users
* there are generic problems with bounce mail handling
* there are known problems with the queue sometimes "jamming"; usually a restart or 'bongo-queuetool flush' can fix this
* there are known problems talking to other SMTP servers using TLS encryption

Because of the large number of changes in this release, we expect that there may be several bugs which will bite people testing 0.6. We do intend to support tester/developers with this release, and this branch will be actively maintained.

== Next Release ==

As a supported branch of Bongo, 0.6 will receive minor updates, and in due course we will make further releases for those people trying to use it in practice.

The next major release will be 0.7. This will be in line with our new time-based release process, and will arrive at the start of October.

We are in the process of updating the [[Roadmap]].

Documentation/Performance

Pfelt — Sun, 26 Oct 2008 21:50:35 GMT

Summary:

On October 25th 2008, I did some informal performance tests using a tool included in the postfix codebase (thanks guys!). The tool is smtp-source. It has lots of tuning options of which I only used a few.

* -s X Number of concurrent sessions or mail delivery threads
* -l X Size of the email body in bytes
* -m X Number of messages to deliver
* -c Display a counter of messages
* -f X Email address for the From: header
* -t X Email address to deliver mail to

The command line that I used for this testing was (run from the bongo server):

<pre>
-s 40 -l 10120 -m 300 -c -f load@feltonline.com -t load@bongo-test.info localhost:25</pre>

The hardware for this test was a Xen VM running on an AMD 64 2.0Ghz single core with 256 MB Ram allocated to it. The dom0 on the Xen provides ip routing functionality but was otherwise idle. Bongo on this system was limited to bongostore (running in gdb), bongoqueue (running in gdb), bongosmtpd, and bongoimap. This will have added overhead as well.

There are two values reported here. The first is the wall time smtp-source used to deliver all the emails. The other is wall time until the queue reported that it was empty as determined by the 10s queue runner seen with debug turned on. (Debug will have slowed delivery a tad). This could also have added, at worst, 10 extra seconds to the wall time. I ran the test 6 times and have averaged the results.

* Dropoff: 62.96867 s
* Delivery: 78.33333 s

I plan on updating these stats as we move along, and also updating them with no debug/gdb.

Releases/0.4.0

Alexhudson — Sun, 07 Sep 2008 19:00:54 GMT

Summary: /* Upgrading */

= Bongo M4 (0.4.0) Release notes =

<div class="warning-alpha" style="margin-top: 15px;">
Bongo is currently alpha-quality software. It is under active development and is not yet ready for production servers.

However, we encourage you to try it out in a test environment and let us know what you think!
</div>

== About Bongo ==

Bongo is a project to create fun and simple mail & calendaring software. As well as providing a well-featured but extensible set of server software, it also comes with a user-friendly web interface.

Although Bongo is a young project, the software itself has a long pedigree going back to commercial products many years old. The core code isn't new, but the ideas we have and the direction we're taking are: we aim to provide a compelling alternative to other systems out there, not to compete directly with them.

We have a roadmap laid out to our 1.0 release, which we hope will appeal primarily to people who are interested in features which make email and calendars more useful, rather than those interested in "groupware" or "enterprise communication platforms". We're particularly aiming 1.0 at power home users, small organisations/businesses, and people providing mail services for third parties.

== What's In This Release? ==

This is the fourth release on the Bongo roadmap. As a source-only release, it is intended only for developers and advanced users who understand they will probably experience bugs and/or rough edges. This is also a server-only release: the web UI is known to have serious faults and isn't usable.

However, we do intend that this release be usable for those brave users willing to try it: our previous release, M3, has been used by a small number and the faults found in it have been remedied for M4. We hope with M4, more people will be willing to take the plunge and try.

== What's New? ==

The main change in this release compared to M3 is an entirely re-worked Store underpinning Bongo; while this isn't very visible to the end user, people using Bongo via IMAP will notice speed and reliability improvements.

The server-side parts of Bongo are now roughly feature-complete and will be changing little between now and 1.0, and we will be supporting people upgrading from version to version for the first time via our mailbox backup/restore system.

== Download and installation ==

You can download the M4 release from the GNA download page:

http://download.gna.org/bongo/release/bongo-0.4.0.tar.bz2

As a quick start, you once you've downloaded the release, you then:

tar -jxf bongo-0.4.0.tar.bz2
cd bongo-0.4.0
./configure --prefix=/usr/local/bongo
make
(as root from here)
make install
cd /usr/local/bongo
./sbin/bongo-config install

We have instructions for compilation in our [[Installation/Source | source guide]] - you will need to fulfill various dependencies, but they are mostly pretty simple.

After you have compiled and installed, you can then set about [[Configuration/Bongo | configuring Bongo]].

Binary packages of Bongo are also being made available on an ongoing basis, but remember that this is still software under development.

== Upgrading ==

You cannot upgrade from Bongo 0.3 to 0.4 by simply installing the new software: the disk format has changed slightly. At the moment, the upgrade method is to backup existing mail boxes and restore them into the new system: however, you need to use the bongo-storetool from 0.4, ''not'' from 0.3!

To backup mail boxes, use a command such as:

bongo-storetool -u <user> -p <password> -h <bongo IP> sb

Leave out the host option if you are on the localhost. This will create a file called <user>.backup, which can then be restored with:

bongo-storetool -u <user> -p <password> sr <user to restore> [<backup file>]

See the bongo-storetool help for further options to store-backup (sb) and store-restore (sr). In particular, you only need to specific the backup file if the username has changed.

If you want to follow this procedure, as a whole you need to:

* backup your mailboxes from 0.3 with the storetool from 0.4
* install bongo 0.4, and run 'bongo-config install' as usual - remembering to specify the right mail domains again
* either add the users again (remember passwords!) or copy your var/bongo/dbf/userdb.sqlite from the old install to the new install to bring back the user auth information
* only then start up bongo 0.4 and restore mailboxes

== Known Issues ==

You may want to review the project bugs page to see a complete list of those issues discovered. At the time of release, the following bugs are known:

* (major) the Dragonfly web UI is unusable for most users
* there are generic problems with bounce mail handling
* there are reports that large numbers of incoming e-mails can cause problems

Because of the large number of changes in this release, we expect that there may be several bugs which will bite people testing M4. We do intend to support tester/developers with this release, and will actively maintain this branch of the software, though.

== Next Release ==

As a supported branch of Bongo, M4 will receive minor updates, and in due course we will make further releases for those people trying to use it in practice.

The next major release will be M5. Coming in that release:

* new, more reliable, web UI for mail and calendar
* complete Hawkeye web UI for administration

There will also be numerous technical advances and bugfixes that may not immediately visible to users.

For further information, see the [[Roadmap]].

Guides/Profiling Bongo

Alexhudson — Mon, 01 Sep 2008 14:23:58 GMT

Summary: New page: = Profiling Bongo = In order to find out what's going on inside Bongo when stuff is going slow, the best tool to use is a profiler. This is a quick guide to using the "gprof" profiler wit...

= Profiling Bongo =

In order to find out what's going on inside Bongo when stuff is going slow, the best tool to use is a profiler. This is a quick guide to using the "gprof" profiler with Bongo.

gprof is part of GNU binutils and will be installed on most developer systems.

== A profiling build ==

You will need to compile Bongo from source to profile, so you'll need to know how to do that or follow [[Installation/Source|this guide]] to compile from source.

Additionally, you need to set two flags before calling autogen.sh (if you get your source from SVN) or configure (if you're using a tarball):

CFLAGS=-pg LDFLAGS=-pg ./autogen.sh [usual flags here]

With all of Bongo compiled and linked this way, we now have a profiling build. The way that this works is that a gmon.out file is created in the working directory when any agent shutdowns down ''normally''.

Documentation/Bongo Query Language

Alexhudson — Fri, 01 Aug 2008 09:59:07 GMT

Summary: /* Overview */

= Bongo Query Language =

A number of store commands can be supplemented with simple queries, which clients can use to get back more specific information than the standard commands and parameters allow.

== Why a query language? ==

It's relatively clear that a number of clients will need or desire data sets which are more specific than our standard commands can return, so this simple query language was put in place. It is also used internally, so many of the commands which seem to do equivalent things are actually translated "under the hood" as it were.

By enabling this flexibility, the store can become a much richer source of information, and reduce the burden on client applications.

== Overview ==

The query language has been designed to be parsed extremely efficiently, and is set-up so that it can be translated readily into SQL commands. As a consequence of this, it is rather less human-friendly than the rest of our protocol, but while it looks strange on the surface, it is extremely easy to use once you understand it.

The language is formed of operators and functions, all of which take two arguments, and the notation is infix: the operator or function name comes first, followed by the two arguments.

The operators are:

{|
!Operator
!Description
|-
| &
| Logical AND
|-
| style="" | |
| Logical OR
|-
| =
| Equivalency / equality
|-
| ^
| String contains / "is like"
|-
| !
| Inequivalence / inequality
|-
| <
| Less than (numeric expressions)
|-
| >
| Greater than (numeric expressions)
|-
| ~
| Bitfield AND
|}

The functions are:

{|
!Function
!Description
|-
| {
| Left-substring of, taking a length and property name argument
|-
| }
| Right-substring of, taking a length and property argument (to be implemented)
|-
| l
| Document Linked to/from, taking a direction (to/from) and a document guid
|}

Expressions are of the form:

[operator] [sub-expression] [sub-expression]
[function] [constant] [constant]

A constant could be an integer, a string, or a document property name (for example, nmap.guid being the guid of the document).

These tokens are parsed thusly:

{|
! Token
! Format
! Regex
|-
| Operator / Function
| All operators/functions are single non-numeric characters
| ^[^0-9]$
|-
| Number
| Numbers are one or more digits
| ^[0-9]+$
|-
| String
| Strings are quoted, and contained quotes are \-escaped
| ^'.*'$ (escaping not represented)
|-
| Property name
| Properties are lower-case alpha-numeric, and may contain periods
| ^[a-z][a-z0-9]+(?:\.[a-z][a-z0-9]+)*$
|}

Because of these definitions, all tokens are unambiguous: they fall into none or exactly one of the above categories.

== Examples ==

In order to understand these examples, you may need to know a little bit about our store protocol already, and how the store operates.

The context of these examples is a request to the store, for example via MESSAGES, and we are using the query to refine the documents returned to only those we are interested in.

There are a couple of quoting issues to be careful of. Not only does BQL itself need quoting, but within the context of the store protocol additional quoting is usually required. For the most part, BQL uses single quotes for quoting, and the store protocol double quotes, so that the two are "compatible".

=== Mail documents from Jim ===

Mail documents have the store type 0x2, and Jim's address is 'jim@example.com', which will be stored in the 'bongo.from' property of any e-mail.

The logic for this query is "(nmap.type = 2) AND (bongo.from = 'jim@example.com')".

In BQL, this becomes:

& = nmap.type 2 = bongo.from 'jim@example.com'

As a store command you might run:

LIST /mail/INBOX "Q& = nmap.type 2 = bongo.from 'jim@example.com'"

Note especially that the whole argument is quoted with double-quotes, so that the store recognises the whole query as the argument.

Installing Avocado

Halex — Thu, 10 Jul 2008 11:02:38 GMT

Summary:

Assuming you've already [[Installing_Crystal|installed Crystal]], you can follow this '''very''' simple guide (note that it does break any changes you make to the serve directory in SVN):

$ cd path/to/crystal/checkout
$ cd serve/
$ rm * -Rf && rm .svn -Rf
$ svn co http://svn.gna.org/svn/bongo/experiments/avocado ./

Now we can start the server!

$ cd ../
$ ./run-crystal.sh

Great! We're done! Head over to http://localhost:8080/ and awe in the awesomeness of Crystal and Avocado working together. :)

Installing Crystal

Halex — Thu, 10 Jul 2008 10:58:19 GMT

Summary: /* Running */

== What is it? ==

Crystal is the new web backend for Bongo. It provides a simplified API and
is much more modular in design. It is invisaged that different services can be
hosted using the same core backend code (for example, AJAX frontend, admin).

Crystal is released under the MIT/X11 license.

== Installing dependencies ==

You will need:
* [http://werkzeug.pocoo.org/download Werkzeug] (latest stable version should work; cloning from Hg head is probably nicer however). Note that this may have its own internal dependencies.

* [http://python.org Python 2.4+]. '''Note that if you're running 2.4, you will still need to install <code>python-wsgiref</code>''' as a separate package to run the internal webserver.

* SimpleJSON.

Optionally, you may also want the [[Store|Bongo store]] installed.

=== Ubuntu ===

The following commands should install the required base dependencies to run Crystal:

<pre>
$ sudo apt-get install python-simplejson python2.5 python-setuptools
$ sudo easy_install Werkzeug
</pre>

== Getting sources ==

To get the latest version of Crystal, simply to a SVN checkout:

$ svn co http://svn.gna.org/svn/bongo/experiments/crystal crystal

== Running ==

$ cd crystal/
$ ./run-crystal.py

and head over to http://localhost:8080 to see your installation working!

You can also just use the sample data provided in demodata by disabling store altogether:

$ ./run-crystal.py --disable-store

== More exciting things ==

You'll probably want to [[Installing_Avocado|install Avocado]] then! Note that at the moment it currently depends on Crystal's Dragonfly module, but in the future it should work with any Dragonfly server.

Documentation/Hawkeye

Igormorgado — Wed, 28 May 2008 21:09:10 GMT

Summary: /* Agents */

[[Category: Hawkeye]][[Category: Documentation]][[Category: M3]]

Bongo project has created many ways to manage users, domains and features, one of them is the '''Hawkeye Web Adminstration Interface'''.

Here will be explained every option of this interface, the main purporse is to be used as cross-reference when needed.

In this documentation we will use ''localhost'', as domain name, you have to change it to fit your needs, the nice thing is, if you're accessing this document from same computer where Bongos is installed, you will be directed to the right page (thanks to [[Guides/Dragonfly_URL_Schemes|REST architecture]]).

== About the interface ==

[[image:hawkeye_desktop.png|right|120px|thumb|Hawkeye interface]]The admin interface is made to be simple, clean and objective. It requires a "modern" web browser to work, because it was made with XHTML. Every page fits very well on screen, even in small displays (800x600), they are divided in 3 main sections.

# Header
# Body
# Footer

[[image:hawkeye_desktop_toggled.png|right|120px|thumb|Sidebar hidden]]On ''header'' you will find the Bongo logo on left side, and username on right side (with a logout button right aside), on ''footer'' there is the tool version and the GPL disclaimer), our main focus lies on ''body'' where we will find all options.
The ''body'' section is divided in two section the left one is the sidebar, where you can browse every subject (better explained later), on right side you will find the sub-sections from every subject choosen previously, if you select any sub-section, you will be taken to Bongo configuration options. You can also toogle the sidebar on/off clicking on label '''Toggle sidebar'''.

== Login screen ==
{{Infobox URL
| image=hawkeye_login.png
| tab=Login
| set=N/A
| handler=N/A
| url=http://localhost:8080/admin/login
}}
This screen is very straight forward, we have just 3 objects, they are:
* Username - A valid username with administrative privileges (see [[Creating Users]]).
* Password - The username password.
* Language - Chooses the interface language.

== Desktop ==

{{Infobox URL
| image=hawkeye_desktop.png
| tab=Desktop
| set=N/A
| handler=N/A
| url=http://localhost:8080/admin
}}

The desktop window is the first window seen after login, it shows some information about Bongo itself and the system where it is installed.

* Agent Status
* Bongo Updates
* System status
* Memory usage
* Load
* Last 5 actions

== Users ==

Not available on M3

== Agents ==

{{Infobox URL
| image=hawkeye_agents.png
| tab=agents
| set=agents
| handler=N/A
| url=http://localhost:8080/admin/agents/
}}

An agent is a subsystem responsible for a very specific task inside Bongo. In ''agents'' tab set, you will find handlers to manage every Bongo agent, there are 12 available agents. They are:

* '''bongoqueue''' - controls the Bongo mail queue
* '''bongosmtp''' - receives e-mail via SMTP protocol
* '''bongosmtpc''' - sends e-mail smtpc via SMTP protocol (the C stands for client)
* '''bongoantispam''' - runs antispam in every message processed by smtp agent
* '''bongoavirus''' - runs antivirus in every message processed by smtp agent
* '''bongocollector''' -
* '''bongomailprox''' -
* '''bongopluspack''' -
* '''bongorules''' -
* '''bongoimap''' - allow users access bongo store via IMAP protocol
* '''bongopop3''' - allow users access bongo store via POP3 protocol
* '''bongostandalone''' -

=== Enable/Disable ===

{{Infobox URL
| image=hawkeye_server.png
| tab=agents/global
| set=server
| handler=N/A
| url=http://localhost:8080/admin/server/
}}

This page allows you to enable and disable specific agents during runtime for change at next restart.

Please note that you must restart bongo-manager for these changes to take effect, since they're only to do with the agent list at startup, not dynamic starting and stopping.

=== SMTP ===

{{Infobox URL
| image=hawkeye_agents_smtp.png
| tab=agents/smtp
| set=agents
| handler=bongosmtp
| url=http://localhost:8080/admin/agents/bongosmtp
}}

This page allows you to manage how '''smtp''' and '''smtpc''' agents will behave. The options are:

{|border=1
!Parameter||Default value||Valid input||Description
|-
|SSL Port||465||1-65535||The TCP port where "bongosmtp" will listen for incoming secure connections.
|-
|Socket timeout||600||numeric||Value in seconds to wait in an idle connection
|-
|Port||25||1-65535||The TCP port where "bongosmtp" will listen for incoming connections (do not change, unless you really know what you're doing)
|-
|Maximum recipients||15||numeric||Max number of recipients per message, if number exceeds, the message will be dropped without any explanation
|-
|Message size limit||0||numeric||Maximum value in bytes allowed in a single message (0 for no limit)
|-
|Allow client SSL||False||Bool||Enable/Disable support to SSL clients
|-
|Maximum MX servers||20||numeric||?
|-
|Maximum threads||10000||numeric||Maximum number of threads spawned for bongosmtp/smtpc agents.
|-
|}

=== IMAP ===

{{Infobox URL
| image=hawkeye_agents_imap.png
| tab=agents/imap
| set=agents
| handler=bongoimap
| url=http://localhost:8080/admin/agents/bongoimap
}}

This page allows every configuration related with ''bongoimap'' handler.

{|border=1
!Parameter||Default value||Valid input||Description
|-
|Port||143||1-65535||The TCP port where "bongoimap" will listen for incoming connections (do not change, unless you really know what you're doing)
|-
|SSL Port||993||1-65535||The TCP port where "bongoimap" will listen for incoming secure connections.
|-
|Maximum threads||50||numeric||Maximum number of threads spawned for ''bongoimap'' agents.
|-
|}

=== Antivirus ===

{{Infobox URL
| image=hawkeye_agents_antivirus.png
| tab=agents/antivirus
| set=agents
| handler=bongoantivirus
| url=http://localhost:8080/admin/agents/bongoavirus
}}

This page allows you to manage how agent '''bongoavirus''' will handle anti virus checks, right now only [http://www.clamav.org ClamAV] is supported. The [[antivirus configuration]] is beyond of scope of this document, and it's covered on [[Documentation/Administration_Guide|Administration Guide]]

{|border=1
!Parameter||Default value||Valid input||Description
|-
|Timeout||15||numeric||Maximum time (in milliseconds) to connect to antivirus server.
|-
|Hosts||127.0.0.1:3310:1||HOST:PORT:?||Colection of hosts:port (one per line), where antivirus servers are configured
|-
|}

=== POP3 ===

{{Infobox URL
| image=hawkeye_agents_pop3.png
| tab=agents/pop3
| set=agents
| handler=bongopop3
| url=http://localhost:8080/admin/agents/bongopop3
}}

This page allows every configuration related with ''bongopop3'' handler.

{|border=1
!Parameter||Default value||Valid input||Description
|-
|Port||110||1-65535||The TCP port where "bongopop3" will listen for incoming connections (do not change, unless you really know what you're doing)
|-
|SSL Port||995||1-65535||The TCP port where "bongopop" will listen for incoming secure connections.
|-
|}

=== Global ===

{{Infobox URL
| image=hawkeye_agents_global.png
| tab=agents/global
| set=agents
| handler=global
| url=http://localhost:8080/admin/agents/global
}}

skel

=== Mail Proxy ===

{{Infobox URL
| image=hawkeye_agents_mailproxy.png
| tab=agents/mail proxy
| set=agents
| handler=bongomailprox
| url=http://localhost:8080/admin/agents/bongomailprox
}}

skel

=== Queue ===

{{Infobox URL
| image=hawkeye_agents_queue.png
| tab=agents/queue
| set=agents
| handler=bongoqueue
| url=http://localhost:8080/admin/agents/bongoqueue
}}

skel

=== Antispam ===

{{Infobox URL
| image=hawkeye_agents_antispam.png
| tab=agents/antispam
| set=agents
| handler=bongoantispam
| url=http://localhost:8080/admin/agents/bongoantispam
}}

skel

== System ==

skel

=== Backup and Restore ===

skel

=== Domain ===

skel

==== Creating a new domain ====

skel

==== Removing a domain ====

skel

==== Editing a domain ====

skel

== Help ==

Not available in M3

Live CD

Lhaig — Tue, 06 May 2008 21:29:58 GMT

Summary: /* LiveCD */

==== LiveCD ====
Once you have started the livecd I know you are eager to start testing Bongo.
Unfortunately you will need to configure the system before you will be able to do that.

Now don't run away it is not as hard as you think, No really.

Use the following steps to configure the livecd so you can play. Just remember that this is a livecd so that really cool e-mail you sent to your special person will be gone once you reboot your machine.

Right down to business.

You should see the following screen once the system has booted

[[Image:BongoLiveCDconsole.png]]

In this screen you can see that we have given you a link to the initial configuration page. The URL looks something like this
https://IPADDRESS:8003 enter it into your favorite browser

don't for get the https or it will error out.

What you should see is this

[[Image:BongoLiveCDraastage1.png]]

On this page you will need to enter the following details
username admin
password password

Then click on submit

You will then be asked to click on OK, this will take you to the root password setting screen that looks like this

[[Image:BongoLiveCDraastage3.png]]

enter a password for the root user make sure you type it in the same both times and then click ok.

You will then be presented with the next page looking like this

[[Image:BongoLiveCDraastage4.png]]

This is the password setting page for the rpath web admin user

you need to enter password as the old password and a new password twice.

Once you are sure you have typed the password in correctly then click change password

The next page looks like this

[[Image:BongoLiveCDraastage5.png]]

This page allows you to set-up the system email account that will receive the update e-mails from the appliance when new bongo or system updates are released.

Enter the following in the fields provided
Mail relay - localhost
Mail From - bongoserver@localhost

Then click OK

The next page will allow you to set-up the people who will receive these update notices.
in the field provided you can add an email address of the recipient. The page should look like this

[[Image:BongoLiveCDraastage6.png]]

you can add more than one person to the list or a mailing list if you want.
As this is not a live server we don't have to be to careful so in the field provided enter
bongouser@localhost and click add

Once you have added the user you can click on the save button.

You should then see this page

[[Image:BongoLiveCDraastage8.png]]

Don't do anything to this page just click on the Done button.

Now we get to the interesting bit.

You should now see the following page

[[Image:BongoLiveCDraastage9.png]]

This is where we configure the base bongo system. We can leave the defaults here and click save.

You should now see the Configure Proxy page. This page allows you to add your network proxy server if you use one so that your Bongo appliance can get its updates from the web.
Once you have entered the proxy server information then you can click on the OK button.

You should now see this page

[[Image:BongoLiveCDraastagefinish.png]]

Congratulations you are finished.

You can now open your browser and enter this link
http://IPADDRESS

You will then see a login page.

Enter the following information
Username – admin
password – bongo

you are now logged in to the bongo server. have fun playing.

Documentation/Store Property List

Alexhudson — Mon, 21 Apr 2008 15:06:57 GMT

Summary: /* bongo namespace */

= Store Property List =

This is intended to be a list of the various properties that the Bongo store automatically gives collections/documents, and also any properties that it otherwise recognizes or that the project has in some way standardised.

== Name format ==

Properties are simple text names, however, we use a simple dot notation to "namespace" them. For example:

nmap.mail.headersize

.. is a valid property in the 'nmap' namespace.

The Bongo Project reserves the 'nmap', 'store', 'bongo' and 'internal' namespaces, and third-party applications must not use them.

== nmap namespace ==

These core properties are effectively read-only, apart from those marked with an asterisk (*), and attempts to PROPSET them will be met with failure.

Properties marked with a plus (+) are obsolete and may be removed in the future.

=== Properties on all Store objects ===

guid
collection
name
length
type
flags
created
lastmodified
version +
access-control *

=== Mail document additional properties ===

mail.conversation
mail.imapuid
mail.sent
mail.subject
mail.messageid
mail.parentmessageid
mail.headersize

=== Conversation document additional properties ===

conversation.unread
conversation.count
conversation.subject
conversation.date

=== Event document additional properties ===

event.alarm *
event.calendars
event.start
event.end
event.location
event.summary
event.uid
event.stamp

== bongo namespace ==

These properties are generated from messages parsed, but are read/write.

=== Mail document additional properties ===

bongo.from
bongo.to
bongo.sender
bongo.cc
bongo.inreplyto
bongo.references
bongo.xauthok
bongo.listid

=== Contact additional properties ===

bongo.contact.name
bongo.contact.email

Although a contact can have more than one e-mail set, we only store one in the properties at the moment - usually, the preferred email. Similarly, we don't store possible variations of names (although that is more of a corner case...)

Installable CD/DVD

Lhaig — Sat, 19 Apr 2008 19:49:25 GMT

Summary: /* Installable_CD/DVD */

==== Installable_CD/DVD ====
Once you have written the ISO to disk insert it in the cdrom of your server.
When the server starts and boots you should see this screen
[[Image:BongoISOInstallStage1.png]]
Hit Enter on your keyboard.

After a while you should see screen like this
[[Image:BongoInstallISOStage2.png]]

Click on Next

You should then see a screen like this

[[Image:BongoISOInstallStage3.png]]

Select your language

[[Image:BongoISOInstallStage4.png]]

Select your keyboard language
Then select Next
You should now see this screen

[[Image:BongoISOInstallStage5.png]]

Appliance Notes
Initial console userid/password
root/<none>
Initial rAA userid/password
admin/password
To manage or update your appliance:
This appliance includes the rPath Appliance Agent (rAA), a web-based appliance management console. The rAA console allows you to:
- retrieve an install updates for the appliance
- configure the appliance's network settings
- initially configure Bongo
- reboot your appliance
In order to access the rAA console, enter:
https://<appliance-ip>:8003/
into your web browser. The default rAA user is 'admin' with password 'password

TryBongo

Lhaig — Fri, 18 Apr 2008 22:14:44 GMT

Summary: /* Try Bongo */

== Try Bongo ==

This page attempts to document the process of using our appliance install medium and Virtual machine images. Please use the links below to get information on your chosen install method.

====[[Live CD]]====
Use this to try the bongo software before installing it anywhere.
====[[Installable CD/DVD]]====
This is a standard ISO image that you can burn to CD and use to install on hardware
====[[Mountable Filesystem (Xen Virtual Appliance)]]====
This is a Xen virtual Machine disk pre-installed and ready to configure
====[[VMware (R) Virtual Appliance]]====
This is a Vmware appliance you can use on the Free Vmware server pre-installed and ready to configure
====[[VMware (R) ESX Server Virtual Appliance]]====
This is a Vmware ESX server appliance pre-installed and ready to configure
====[[Microsoft (R) VHD Virtual Server]]====
This is a Microsoft Virtual disk pre-installed and ready to configure
====[[Amazon Machine Image (Xen Virtual Appliance)]]====
This is an image you can use at Amazon pre-installed and ready to configure

Google Summer of Code/Application2008

Alexhudson — Sun, 09 Mar 2008 14:11:40 GMT

Summary: /* Some Specific Questions */

__NOTOC__
= Google SoC Student application =

This is our proposed application form for students applying to the Bongo Project.

== Name & Contact Details ==

Please provide your contact details: at the minimum, a name and e-mail address.

Name:

E-mail:

Address/location:

Phone:

== A Short Bio ==

Please tell us a little about yourself. In particular, what you're studying (and how far into your course you are), and detail any previous experience in the free software community or participation in a free software project.

The Bongo Project prides itself on fun and friendliness: as well as technically adept students, we also want people who will fit our culture. So, remember, we're not just interested in your technical skills, but also your "people skills".

== Your Proposal ==

What would you like to do? Please give us a high-level description (what functionality and/or end-user use cases you're addressing) and a more detailed technical discussion (protocols that might be implemented, for example). Point out which areas you have existing knowledge and/or experience, and which areas will be novel either for you, for the Bongo Project, or present novel ideas/functionality in general. What technical skills would you use doing the project, and what skills would you gain?

Outline a project plan as best you can. This should begin with a period of some research and/or planning, end with a brief project report, and have a number of stages in between by which progress can be measured. Goals should be simple and measurable: for example, having code reaching a certain point in terms of functionality. If you have specific dates in mind, please include them.

Whereever possible, define the outputs you envisage, and how much effort each output would require in your estimation. Include time for writing status reports for the project, the final report, time spent with your mentor - particularly if you see specific points during the project where close mentorship would be especially important. Define the code output as clearly as possible: calculate the work effort for each feature, the supporting test suite, etc. If possible, include estimates of risk with each work product, to show how confident you are in your estimate.

There is no right and wrong with a project plan: for example, saying that you are not confident with certain aspects of your plan is fine. We're much happier with a realistic and honest approach to planning, rather than one which tries to convince us of how successful you will be. Remember, success isn't just the avoidance of failure: success is anticipating and encountering failure, and making progress regardless - in many ways, we'll be more impressed by your plans for failure. You may also want to think about having some kind of "Plan B" where there is a risky part of your plan.

== Some Specific Questions ==

There are a number of questions we'd like all potential students to answer, to help form a picture of who you are, what you want to do, and why we might want to pick you.

* Why should we pick this proposal? We want the best students and the best ideas - what makes your project the ideal combination?
* What impact would your project have on Bongo, and what (if any) impact would it have on free software more widely?
* How do you see your day-to-day work progressing, and how many hours do you estimate you will be working on your project per week?
* What other commitments on your time will you need to manage during the programme?
* Ideally, your participation in Bongo would begin before your project starts, and we hope that you would continue to participate well after your project finishes. However, nothing is guaranteed - if your participation finished with the project, how would your contribution live on?

Google Summer of Code/Ideas2008

Alexhudson — Sun, 02 Mar 2008 09:58:53 GMT

Summary: /* A Python library for parsing natural dates */

= Ideas for GSoC 2008 =

These ideas represent merely a starting point. Bongo, right now, can be improved specifically in a number of key areas:

* Contacts. Shared contacts at the moment are a pain for free software, and few clients agree on how to look up contacts.
* Synchronisation. There are some decent implementations of synchronisation software and protocols; it would be really useful to integrate one.
* Collaboration on the web. We have a number of ideas about how to collaborate on line; specifically, we want to move towards a point where you can collaborate freely with other people, whether or not they are Bongo users.

Many of the ideas below address some of the problems in these areas, but they shouldn't be seen as a fixed list of the only things we're interested in, just a beginning.

=== For people proposing ideas ===

Each project should have some standard information:

* what the specific outputs and objectives would be
* whether any work has already been done which can contribute to the project
* what skills would be necessary/desirable for the student to be able to complete the project
* how easy and important the project is, on a scale from 1-5 (1 being not very easy/not very important, 5 being very easy/important)
* who the mentor might be

At some point we probably should split out this information into a specific page per-project, to expand on the information here.

[[Google Summer of Code/Ideas2007|Ideas from 2007]] are also still valid.

== General Projects ==

These are things which Bongo could really use, but would be widely helpful outside of the Bongo project. These would suit someone who had experience of these libraries/etc. in general, and no knowledge of Bongo would be required.

=== libical replacement ===

Currently we use the libical library for reading/writing iCal files. However, it suffers from a number of problems: sketchy maintenance, memory leakage, potential buffer overflows. It has been forked a number of times over the years, and although it is embedded in a number of projects it is a painful code base to maintain.

For Bongo, iCal data is often likely to be external - it will come from outside sources. Such data should be treated as potentially harmful, and the current libical is not the best framework for such an approach.

What would be useful would be a library designed around a "proper" parsing framework, with strong guarantees to parsing safety, security and fault detection and handling.

Skills required: C language, iCal knowledge, building safe parsers.

Ease: 2/5
Importance: 1/5
Mentor: Alex

=== SQLite ORM ===

Bongo's use of SQLite is pretty straightforward and standard, but is complicated by the fact that a lot of code needs to be written to do things which should be easy, like caching queries, managing transactions and creating new queries.

In particular, common code patterns (such as reading a line out of a database, updating the data, and then re-saving the data) is time-consuming.

All these problems could be solved by using a code-generating ORM or ORM-like layer which takes a description of the database and creates a GObject-like API to the "objects" in the database, which handle all the details of actually reading and writing.

The emphasis should be on utility, not the notional "purity" of OO database access. It is about saving work creating code, trusting the code to be more correct, and effectively having a higher-level API into the database. Thought should be given to how programmer time can be saved, and what common patterns there are (or, could be) in SQLite consumers. More "academic" concerns, such as forming query builders from OO data relationships, are of less interest since SQL WHERE clauses are easily written - it's the mechanics of access which is the problem.

Skills required: Knowledge of SQL, the SQLite library, C language, OO.

Ease: 3/5
Importance: 5/5
Mentor: Alex

=== A Python library for parsing natural dates ===

Ruby has an excellent little library called [http://chronic.rubyforge.org/ Chronic] which interprets English strings as dates. This is similar to the libcalcmd C library already integrated into Bongo.

Both these solutions suffer from one large problem from our point of view: they're neither multi-cultural nor multi-lingual. For example, the English phrase "Let's meet a fortnight tomorrow" is parsed as the day after today, not fifteen days' time.

Another substantial limitation is that they undertake to solve a problem exactly where often the answer will be ambiguous. For example, for some speakers "next Wednesday" may mean "Wednesday next week", or "the Wednesday after the one coming" - both answers could be correct. Similarly, Japanese has a concept of "jun" which represents one third of a month - an ambiguous time range. By limiting themselves to a single date/time answer, the libraries reduce their usefulness, since they could offer the user a range of options.

This would be a complex project to undertake, and certainly a student would have trouble completing a library which works for a single language, let alone several. This project should, therefore, take the approach of a prototype or research into how such functionality can be built.

Outputs could include a study of a variety of language and calendar systems, with implemented parsers which can extract key pieces of data and have some notion of "time/date grammar". It would also be useful to have some kind of representational system for date/times and ranges so that new parsers could be implemented and integrate into existing ones: for example, "Wednesday in Week 42" is a valid construct, and may be very useful for certain business users.

Skills: Students who have knowledge of different languages, and especially calendar systems, would be best suited. Knowledge of parsing and Python is obviously also a huge advantage ;)

Ease: 2/5
Important: 3/5
Mentor: ?Alex

== Bongo-Specific Projects ==

These projects are Bongo-specific, and will be of much less use to other projects.

=== Make Bongo an OpenID provider and consumer ===

Bongo has an auth subsystem, and creating an OpenID provider from that would be extremely simple. This would allow Bongo users to use their Bongo address as a log-in elsewhere. This would be the first milestone of this project.

The second milestone is tougher: making Bongo an OpenID consumer. Primarily, this would involve altering the Bongo data store to recognise OpenID authentication tokens, and adding the ability to authenticate OpenID to the auth library.

Skills required: Python, C, OpenID.

Ease: 4/5
Importance: 4/5
Mentor: Lionel

=== Create "Getting Things Done"-type tools for Bongo Web UI ===

The GTD methodology is very popular, but their are few apps which provide tools for people using it - although there are various guides about how you can adapt the various features mail clients provide in order to do things according to GTD.

This project would identify a small number of key tools which would make using GTD methods a lot easier with Bongo, and then write them as plugins to our webmail system. The main difficulty with this project will be adapting to web UI which isn't yet finished, so the student involved will have a strong influence on the development of this important part of Bongo.

Skills required: GTD knowledge, Javascript, possibly some Python.

Ease: 4/5
Importance: 3/5
Mentor: Lionel

=== Renew the Bongo Python bindings ===

Bongo currently has extensive Python bindings which give applications direct access to the store and queue, and which cover the large proportion of Bongo functionality. However, they could be improved.

One problem is that they depend on Bongo's C libraries being available: there is no reason why these libraries couldn't be pure Python. This would give us the ability to package them separately, and release them separately, so that code for other projects could sensibly be written (sync. connectors, for example).

Another problem is that they are very line-oriented rather than event-oriented. This makes it virtually impossible to use the out-of-band messaging from the Bongo store (since the OOB messages come at times when the Python is expecting a different response). The API should be adjusted to be more Twisted-like.

A basic design and code for this API has already been completed, so the student will not be starting from ground zero. The student would also be expected to complete a test suite for the API.

Skills required: Python, knowledge of networking sockets, asynchronous programming

Ease: 5/5
Importance: 5/5
Mentor: Alex

=== Integrate a Jabber server ===

Instant messaging and e-mail messaging shouldn't be separate worlds; they should just be different sides of the same coin. In that vein, it would be interesting to see some possibilities of integrating an existing Jabber server into Bongo.

This should include using the Bongo authentication system (or some authentication system which both Bongo and the Jabber server can access), taking buddy information from the user's addressbook (and/or merging with the Jabber service), and storing records of conversations over IM in the user's store so that they are able to archive and search over previous IM conversations in the same way as they can e-mails (use case: you know you spoke to Bob about the product launch, so you search all your conversations with Bob. That turns up two e-mails and a follow-up IM conversation, giving you the complete view).

Additionally, it would be good to have a written document as an output, giving consideration to how the Jabber/IM concept of "Presence" could/should be integrated into Bongo, both at a user interface level and at a more technical level.

Skills required: knowledge of Jabber, preferably C for the Jabber server, and some Bongo store knowledge.

Ease: 4/5
Importance: 3/5
Mentor: Pat/Alex

=== CardDAV support for Bongo ===

CardDAV is the up-and-coming protocol to do server-side contacts read/write and sharing with other users. In many respects, it is very similar to CalDAV, so work on this project will probably mean that it isn't a ground-up project: the existing CalDAV code can be improved and adapted to provide CardDAV support.

We would agree the outputs up front in addition to a CardDAV server. These outputs may include:

* specific enhancements to the CalDAV system;
* a CardDAV test suite and/or exemplar CardDAV client;

Skills required: Python, knowledge of DAV, knowledge of the Bongo store

Ease: 3/5
Importance: 4/5
Mentor: Jonny

Documentation/Crystal/SessionInfo

Halex — Fri, 29 Feb 2008 10:54:09 GMT

Summary: New page: TODO == Properties == === user === '''Type:''' String<br /> '''Default:''' null Username associated with session. === uid === '''Type:''' Integer<br /> '''Default:''' -1 Current sessi...

TODO

== Properties ==

=== user ===
'''Type:''' String<br />
'''Default:''' null

Username associated with session.

=== uid ===
'''Type:''' Integer<br />
'''Default:''' -1

Current session ID.

=== authprovider ===
'''Type:''' String<br />
'''Default:''' null

Authentication provider name associated with this session instance.

=== cache ===
'''Type:''' [[Documentation/Crystal/Cache|Cache]]<br />
'''Default:''' null

Current cache instance.

== Methods ==

=== close () ===

'''Returns:''' Boolean

Does nothing for the moment. <code>:)</code>

== Example ==

TODO!

Documentation/Crystal/HandshakeRequest

Halex — Fri, 29 Feb 2008 10:06:48 GMT

Summary: New page: HandshakeRequest manages and initialises a new remote session via the [[Documentation/Crystal/SessionInfo|SessionInfo]] object. == Constructor == new HandshakeRequest (user, handler, [p...

HandshakeRequest manages and initialises a new remote session via the [[Documentation/Crystal/SessionInfo|SessionInfo]] object.

== Constructor ==

new HandshakeRequest (user, handler, [password])
{|
!Name
!Type
!Required
!Description
|-
|user
|String
|Yes
|Username, email or similar field used to pass to the authentication provider.
|-
|handler
|String
|Yes
|Authentication provider on the server to use. Examples include 'store', 'openid', and so on.
|-
|Password
|String
|No
|Either plain-text or hashed password to be passed to the authentication provider along with the username. Not required by all authentication providers.
|}

== Properties ==

=== authSuccessful ===
'''Type:''' Function<br />
'''Default:''' null

Function to run when the handshake has completed and run without fail. The function will be run with a single argument, the [[Documentation/Crystal/SessionInfo|SessionInfo]] object for the newly created session.

=== authFailure ===
'''Type:''' Function<br />
'''Default:''' null

Function to be run when the handshake failed on the server. This is generally ''not'' a web exception; use the <code>requestFailure</code> property for that purpose. This function will be called with two arguments, the error code, followed by the error message (en_US only). Please base internationalisable error messages off the error code, rather than the message returned; it should only be used for debugging/testing.

=== requestFailure ===
'''Type:''' Function<br />
'''Default:''' null

Function to be run when the data query encounters an error. This can be assumed to be a web-related exception. The function will be called with the same arguments as run by MooTools's Request onFailure event. See http://docs12b.mootools.net/Request/Request#Request:events for more information.

== Methods ==

=== run () ===

'''Returns:''' nothing

Runs the current HandshakeRequest instance asynchronously. Calls authComplete when the user has been successfully authenticated and a new session created, and authFailure if there was an authentication error.

== Example ==

var a = new HandshakeRequest ("rupert", "store", "mypassword");
a.authSuccessful = onAuthComplete;
a.run ();

Google Summer of Code

Alexhudson — Fri, 29 Feb 2008 09:23:24 GMT

Summary: New page: == Summer of Code == === 2008 === We're currently working on this. * [[Google Summer of Code/Ideas2008|Propose some ideas]] * [[Google Summer of Code/Application2008|Proposed applicatio...

== Summer of Code ==

=== 2008 ===

We're currently working on this.

* [[Google Summer of Code/Ideas2008|Propose some ideas]]
* [[Google Summer of Code/Application2008|Proposed application form]]

=== 2007 ===

We weren't successful this year :( But, you can review [[Google Summer of Code/Ideas2007|the ideas]] and [[Google Summer of Code/Application2007|the proposed application form]].

Web Stack Todo

Halex — Tue, 26 Feb 2008 09:55:03 GMT

Summary: New page: * Split up mail stuff from mail views.py into separate module * Implement templating system into utils.py, so that plugins can use them later * Test cases (possibly auto-test cases/tools?)...

* Split up mail stuff from mail views.py into separate module
* Implement templating system into utils.py, so that plugins can use them later
* Test cases (possibly auto-test cases/tools?)
* Docs, docs, docs!
* Create module loader stuff, so that we can have any module and get it to plug into the core and let it setup its URL routing (pathing), own modules, etc. See main 'Crystal' section (middle) on diagram: http://mediati.org/temp/more-avocado.png
* Implement mail-sending code
* Implement calendaring code

Documentation/Crystal/DataQuery

Halex — Tue, 26 Feb 2008 08:57:52 GMT

Summary:

DataQuery is basically a simple wrapper around a XMLHttpRequest, that handles URL structure, error handling and caching transparently.

== Constructor ==

new DataQuery (handler, session, arguments, cacheable, ident)
{|
!Name
!Type
!Required
!Description
|-
|handler
|String
|Yes
|Describes the server handler that will take the request and run it.
|-
|session
|[[Documentation/Crystal/SessionInfo|SessionInfo]]
|Yes
|The current authenticated session to use requests with.
|-
|arguments
|Associative array
|Yes
|Describes the optional arguments to pass along with the web request to the server as JSON. There are a few parameters that are used directly by the DataQuery object itself. These include:
* <code>urlargs</code>: URL to append to the end of the original request path. For example, if the original request path is http://mysite.com/sessionid/mail/, the value of <code>urlargs</code> would be appended to that string and used as the URI when the request is run.
|-
|cacheable
|Boolean
|No
|Whether or not the result of the DataQuery should be cacheable or not.
|-
|ident
|String
|No
|Key used against the arguments parameter to uniquely identify the current DataQuery.
|}

== Properties ==

=== dataComplete ===
'''Type:''' Function<br />
'''Default:''' null

Function to run when data query has completed and has data. The function will be run with a single argument, the decoded JSON data.

=== dataFailure ===
'''Type:''' Function<br />
'''Default:''' null

Function to be run when the data query encounters an error. This can be assumed to be a web-related exception. The function will be called with two arguments, the error code, followed by the error message (en_US only). Please base internationalisable error messages off the error code, rather than the message returned; it should only be used for debugging/testing.

=== cacheable ===
'''Type:''' Boolean<br />
'''Default:''' false

Whether or not the results from the data request should be cacheable.

== Methods ==

=== run () ===

'''Returns:''' nothing

Executes the current DataQuery instance asynchronously. Calls dataComplete when the data has been fetched, and dataFailure if there was an error.

A HTTP GET request is performed by the browser's XMLHttpRequest object.

== Example ==

var q = new DataQuery ("mail", [[Documentation/Crystal/SessionInfo|session]], { mailbox: "INBOX" };
q.dataComplete = function (msg) { alert (msg); };
q.dataFailure = function (code, msg) { alert ("Error occured: (" + code + "): " + msg); };
q.run (); // run worker async

Documentation/Crystal

Halex — Tue, 26 Feb 2008 08:44:01 GMT

Summary: /* Server-side API */

== Client-side API ==

=== Classes ===

* [[Documentation/Crystal/DataQuery|DataQuery]]
* [[Documentation/Crystal/HandshakeRequest|HandshakeRequest]]
* [[Documentation/Crystal/DateFormatter|DateFormatter]]
* [[Documentation/Crystal/Gettext|Gettext]]
* [[Documentation/Crystal/Cache|Cache]]
* [[Documentation/Crystal/DataQueryParamRegister|DataQueryParamRegister]]

=== Data types ===

* [[Documentation/Crystal/SessionInfo|SessionInfo]]

== Data Transport ==

TODO.

== Server-side API ==

Future Ideas

Halex — Sat, 19 Jan 2008 07:34:40 GMT

Summary: New page: Here are some ideas which we might be working on in the future: * [[Avocado]] - our new web UI for Bongo users. * [[Flasher]]

Here are some ideas which we might be working on in the future:

* [[Avocado]] - our new web UI for Bongo users.
* [[Flasher]]

Avocado

Halex — Sun, 16 Dec 2007 07:09:44 GMT

Summary:

Currently in the planning stages, '''Avocado''' is the web UI, intended to replace [[Dragonfly]]. [[Crystal]] makes up the server backend, and the Javascript message transport API.

== Status ==

Code is currently under development. We're hoping to put this in the next major release. Basic read-only mail support is working. Some key features underway:
* Pagination
* Mail composition
* Setting properties on mail (eg read/unread, staring).

== Installation ==

For the brave, you can try out Avocado [[installing Crystal]] and then moving on to [[installing Avocado]] on top of it.

== Features ==

This section won't be complete until we finish a prelim release. :)

=== Core plugins ===

As Avocado is modular in design, the core of Avocado would only contain the interfaces and API, as well as a GUI skeleton. The following plugins would be available together with the core Avocado release to provide some sort of functionality to the end user:

* [[/Mail|Mail]] (in progress)
* [[/Calendar|Calendar]]
* [[/Summary|Summary]]
* [[/Contacts|Contacts]]
* [[/Instant Messaging|Instant Messaging]]

== Some planning stuff that needs cleanup ==

=== Target userbase ===

* Personal computers?
* Mobile devices?
* Non-Bongo users?

=== Project aim ===

To provide a clean, well thoughtout, accessible web interface for <target userbase>, solving some portion of the issues presented in the 'Problems' section below.

=== Problems ===

There are several problems associated with current email and calendaring clients. Design for these clients has not changed over the past few years, to keep up to user's changing demands. This section describes several of these issues.

==== Information overload ====

We need to provide a way to cut down the information displayed to the user to only the things he/she needs or wants.

==== Keeping track ====

Many users get lots of email everyday, and a majority of the time, they are not responded to immediately. This could be because the user is awaiting on something or somebody else, or need to attend to more important issues. It is common for the user to become 'lost' under the volume of mail they recieve and forget about the other emails they need to respond to. Other people have lots of calendar appointments, and it often becomes hard to manage all their appointments, especially when you need to co-ordinate things with others.

==== Locating information ====

It often becomes hard to track down information quickly. Email search is generally quite limited and slow, subjects aren't always useful, and email does not contain all that much context. Some users sort their mail into 'folders' as to make it easier to find some information in the future. However, this adds a management overhead to their day-to-day mail - some people spend an inordinate amount of time cleaning up their inbox into folders.

==== Disjointed workflow ====

Relationships between objects are almost non-existant in some email clients. Calendar items, emails and chats are seen as seperate objects, when they could quite easily relate to the same thing. Creating an appointment after discussing times and a location with your contacts via email and IM requires you to manually collate the information about possible times, decide what would be best for everyone, setup a calendar event, email everyone about the final date/time, and get them to confirm. This honestly requires a lot of work on the part of the user; possibly a reason eletronic calendaring is not utilised by many.

==== Staying in sync ====

Many people use mobile devices, as well as many new Web 2.0 websites. These all use slightly different sets of data. We should be able to share all this information, and collate this into something useful. For example, it takes a while for you to manually import all your contact information from your mobile phone; you might be able to gather data you don't currently have about your contact(s) - for example, if you only know the name of a representative from Yoyodyne Corp., you could sync with her contact information, and automatically fill in her work phone number, address etc.

==== Overloading email ====

Although email was originally designed as a asynchronus communication tool, it is now being used for other tasks, including information management, task management, contact management, record keeping and file transfer.

=== Observations ===

* Flags are useless.
* Users don't like automatic filing systems.
* Users can be classified as "No-filers", "spring cleaners" or "frequent filers".
* Users are often control freaks when it comes to displaying information.
* Programs should not force users into a particular way of organising emails, however, it can be allowed to nudge them in a particular direction (this should be editable as a setting if it could be coming annoying, however).
* Users often mistrust filters.
* If a message is out of sight, then the user is very likely to forget the message ever existed.
* Todos are very important, and should be linked to mail; with or without a due date.
* Almost all email in users' inboxes that are not classified as "frequent filers" can be deleted if it has been read.

=== Ideas ===

Feel free to jot down your ideas here!

{|
!Component
!Name
!Description
!Helps solve
|-
|Mail
|Thread Arcs
|Thread arcs are a compact overview of the other messages in a thread and their relationships to each other. One can navigate to these other messages via the visualisation without having to go back to the Inbox list.
|Locating information
|-
|All
|Relation-based suggestive actions
|Allow objects (emails, calendar items, contacts) to have other, similar items linked together. Items created by automatic actions (eg clicking on a date in an email to make an appointment) should generally be automatically linked, so that the email and appointment are related. Provide a way to see other likely related objects by performing a search in the background and display related results.
|Locating information, keeping track, disjointed workflow
|-
|All
|Context-based suggestive actions
|Provide links to start actions based on the context of the link/sentence/object. Dates in emails and chats (eg "tomorrow", "at 7PM") should be clickable to make appointments (with the email referenced, see above); names of contacts should provide 'contact cards' with the ability to initiate chat, etc.
|Disjointed workflow
|-
|Mail, Calendar
|Object Sources
|Many applications use email as a notification mechanism. For example, changes in a collaborative web site (eg a wiki), or transaction confirmations (like an Amazon book purchase) trigger automatic email messages. It could be possible to integrate each of these sources into the message view, so that you could have your RSS feeds or purchase progess alongside your email, while still being to toggle these sources on and off without affecting mail. You can also search and sort through these seperately.
|Information overload, locating information, overloading email
|-
|Mail
|Weighted messages
|Emails could be weighted in three categories: contacts with/without a star; factor of whether or not the user has replied to the conversation (making it more important if he/she has); and weighting conversations in reverse proportion to the number of recipients the original email received (however, this shouldn't not change a message's weighting as much as the other two categories) - this enables removal of low content high noise conversations such as mailing list flames. This could be also be weighed contually on all new messages to the conversation? We could discuss the exact algorithm when the time comes to implement it.
|Information overload, keeping track
|-
|Search
|Instant filtered search
|Instant 'type-and-refine' search is quite often fast and useful to the end user, as it enables them to quickly navigate to whatever they need using the least amount of effort. They can instantly see whether a keyword is returning the right results, and if it is, it allows the user to not type more than is required to get the search results they need. Search should be provided by filtering both the current view, and searching the entire system; the option provided via a dropdown or radio button. The view should not change if filtering, merely removing non-matching items.
|Information overload, locating information
|-
|Mail
|Dual-mail view
|As many users primarily 'live' in their inbox, it makes sense to keep this the most relevant to the user. Only unread messages would ever live in the Inbox, read messages marked as done or archived live in Archived. Messages can be in other states, such as Postponed, etc. See the Inbox Zero idea below for more information.
|Information overload, keeping track
|-
|Mail
|Inbox Zero
|Basically, provide mail to be in all the states (actions) he described. Marking as done makes it read (archived), deleted etc. I should probably fill this in and be more descriptive, but it's getting late.
|Information overload, keeping track
|}

Development/Design/Agents/AgentIdeas

Lhaig — Thu, 15 Nov 2007 13:39:29 GMT

Summary:

== Agent Ideas ==

This is a list of potential ideas that we might want to implement as Agents.
This is drawn from existing functionality, functions other people have, etc.
This should help us design new agents for the system which can meet many, but not all, needs.

=== Bongo Agents ===

==== Mail Management Agent / Assistant ====

After reading Alex's mugshot post about "I want Sandy" We thought that it would be cool to have a similar type of agent in bongo that would do this for us. http://www.boingboing.net/2007/11/14/i-want-sandy-perfect.html

Alex mentioned some things in IRC which I will list here
* An assistant type widget aka "clippy" in Dragonfly that will alert you when you need it
* when not in Dragonfly you email yourself to get things added or deleted from your assistant
* Allow others to interact with your assistant

* Dragonfly
** While logged in to Dragonfly the assistant will notify you via a pop-up about upcoming appointments or events that are in your diary/ calendar
** When you create a new appointment in the calendar you can select to have the assistant monitor it and do things to it as specific times or dates
** When the assistant appears you have the ability to reschedule the appointment with all the invited people

* Incoming e-mail
** When you receive a specially formatted e-mail via SMTP it is sent to your assistant and it deals with the request
** you can send your assistant e-mail to request information they control
*** Appointments
*** Anniversaries
** Auto responds when you are away as booked by your calender
** You can add or remove things from your diary be sending yourself an email
** You can manage appointments and events via email e.g. move, reschedule, etc.

* Other Bongo users
** When other bongo users schedule appointments or events with yourself your Assistant can respond with your busy free schedule via e-mail.
** Other bongo users can query your Assistant to see if you are available via e-mail

Bongo-config

Halex — Mon, 29 Oct 2007 07:43:08 GMT

Summary:

{{Stub}}

'''<code>bongo-config</code>''' is a new Bongo utility that enables you to do several things:

* User administration, up to and including:
** Adding and removing users
** Changing users passwords
* Install base Bongo data (used during inital setup and reinstalls)
* Generate cryptography information for Bongo
* Check versioning information of Bongo online
* Update timezone information on the local system

Bongo-manager

Halex — Mon, 29 Oct 2007 07:40:00 GMT

Summary: New page: {{Stub}} bongo-manager is an application which is used by Bongo to launch the [[agent]]s as specified by the user. It is similar in a way to init as it starts all the daemons before provi...

{{Stub}}

bongo-manager is an application which is used by Bongo to launch the [[agent]]s as specified by the user. It is similar in a way to init as it starts all the daemons before providing you with a usable system.

Agent

Halex — Mon, 29 Oct 2007 07:18:51 GMT

Summary: New page: An '''agent''' is a standalone piece of software in Bongo, similar to a Unix daemon. Agents in Bongo tend to be very specialised and light-weight compared to their Unix counterparts: for e...

An '''agent''' is a standalone piece of software in Bongo, similar to a Unix daemon. Agents in Bongo tend to be very specialised and light-weight compared to their Unix counterparts: for example, a Unix MTA may speak SMTP, run a mail queue and deliver mail. In Bongo, that is separated into three separate agents.

== Bongo's agents ==

Bongo comes with several agents. These include:

* an [[SMTP]] agent
* an [[IMAP]] agent
* an antivirus agent
* a [[queue]] agent
* a [[store]] agent
* a [[POP3]] agent

among others.

== Writing your own ==

Check out the 'generic' agent (in <code>src/agents/generic</code>) for some information as to how you should write your agent.

Hawkeye

Halex — Mon, 29 Oct 2007 06:55:02 GMT

Summary:

{{Stub}}

Hawkeye refers to the web administration component of Bongo. Development began around April, headed by Alex Hudson. Alex Hixon is now also currently a major contributer to the interface, providing a new layout and agent handlers.

== Features ==

Hawkeye supports the following features:

* Modifying agent configuration on-the-fly.
* Enabling and disabling agents.
* Viewing system status and possible updates.
* Backing up and restoring system data.

The following features are planned but not yet implemented:

* Ability to add/modify users, both normal users and administrators.
* Functionality to stop/start/restart Bongo from within the interface.
* Functions to change default Dragonfly configuration and constraints.

== Screenshots ==

[[Image:Hawkeye-desktop.png]]

== Documentation ==

No documentation for Hawkeye is available at this stage.

Crystal

Halex — Mon, 29 Oct 2007 06:38:49 GMT

Summary: Nuke most content.

{{Stub}}

Crystal is the codename for the core of the new web core for Bongo, which is currently in development. It is the intended successor of the [[Dragonfly]], working along together with [[Avocado]].

Configuration/Bongo/Legacy

Halex — Sat, 27 Oct 2007 23:21:41 GMT

Summary:

== Set-up Bongo ==

Run <tt>bongo-setup</tt> (this needs to be run with root privileges):

<pre>$prefix/sbin/bongo-setup</pre>

<tt>bongo-setup</tt> has a number of options. You can change the ports where services will be started and configure Bongo to run against a corporate directory. By default, Bongo will be configured to run SMTP, IMAP, and POP3 on their standard ports.

#If <tt>bongo-setup</tt> terminates after the main introduction, with the message "''ERROR: A possibly stale bongo-manager pid file has been found.''", then this means that Bongo is already started. To stop Bongo, follow the relevant instructions below depending on how you installed Bongo:
#:;Compiled from source:
#::<pre>sudo killall bongo-manager</pre>
#:;Debian or Ubuntu packages:
#::<pre>sudo /etc/init.d/bongoproject stop</pre>
#:;Fedora, CentOS or Redhat Enterprise Linux packages:
#::<pre>sudo service bongo stop</pre>
#:;SUSE packages:
#::<pre>sudo /etc/rc.d/init.d/bongo stop</pre>
#When asked "''Which driver would you like to use for the directory?''", although there is a <tt>file</tt> option, to allow running without an LDAP server, it's advised to use the <tt>managed-ldap</tt> option: that works much better, and you may encounter odd bugs otherwise. '''Note''': This needs the <tt>slapd</tt> package installed.
#You should accept the default for the question "''Enter file for importing objects:''" unless you know what you're doing here.
#When asked ''Enter the hostname for the mail server hosting Bongo [localhost.localdomain]:'' one should probably accept the default unless you know what you are doing.
#When asked ''Enter the domain name that Bongo will host [localhost.localdomain]:'' one should enter a single domain without any prefixes like <tt>www.</tt> or <tt>mail.</tt>. Examples of correct domain names are: <tt>bongo-project.org</tt>, <tt>debian.org</tt> or <tt>berlios.de</tt>.
#When asked ''Enter IP address on which to run Bongo [127.0.0.1]:'' one should probably accept the default.
#You should not be alarmed at the "''ERROR: Could not add attribute BongoDomain''" message. This always occurs.

== Install Bongo Configuration ==

Simply execute:

<pre>$prefix/sbin/bongo-config install</pre>

== Change admin password and add a user ==

Firstly, you should change the password of the admin user. It defaults to "<tt>bongo</tt>". This can be changed by executing (as root):

<pre>$prefix/sbin/bongo-admin user-passwd admin</pre>

You will now need to add a new user to continue. Execute the following command (as root) to add a demo user with username "rupert", password "bongo":

<pre>$prefix/sbin/bongo-admin demo</pre>

'''Note:''' Users can be added/removed/edited later on by using the <tt>bongo-admin</tt> command later. [[Command/bongo-admin|Click here for more information]].

== Start Bongo ==

If you compiled Bongo from source, follow the ''Source'' section, otherwise follow the ''Packages'' section:

==== Source ====

Run <tt>bongo-manager</tt> (as root), which takes no arguments.

<pre>$prefix/sbin/bongo-manager</pre>

Bongo is now running! '''Note''': This will run in the current terminal- to run it as a daemon, add an ampersand after the command:

<pre>$prefix/sbin/bongo-manager &</pre>

=== Packages ===

;Debian or Ubuntu : <pre>sudo /etc/init.d/bongoproject start</pre>
;Fedora, CentOS or Redhat Enterprise Linux : <pre>sudo service bongo start</pre>
;SUSE : <pre>sudo /etc/rc.d/init.d/bongo start</pre>

Documentation/Architecture

Halex — Sat, 27 Oct 2007 01:19:16 GMT

Summary: /* Core binaries */ speiling

{{Stub}}

Bongo is made up of several components:

* Core libraries (msgapi, etc)
* Core binaries/utilities (bongo-manager, bongo-config, ...)
* Agents (bongosmtp, bongoimap, ...)
* [[Dragonfly]], the email/calendar web interface
* [[Hawkeye]], the web administration interface

A diagram showing the relationship between these components would be awesome here.

== Core binaries ==

The core binaries that come with Bongo include:

* <code>[[bongo-manager]]</code>
* <code>[[bongo-config]]</code>
* <code>[[bongo-backup]]</code>
* <code>[[bongo-standalone]]</code>
* <code>[[bongo-storetool]]</code>

There are others, but they are generally un-used or deprecated.

Welcome to Bongo!

Halex — Mon, 22 Oct 2007 10:13:15 GMT

Summary:

<div class="welcome-msg">
''"Bongo is an easy-to-use mail and calendar system, offering a simple yet powerful user interface. The goal is to make sharing, organisation, and communication simpler, quicker, and more useful."''
</div>

{{Welcome_boxes}}

<div class="splits">
<div class="split-half" style="width:60%;">
=== What is Bongo? ===
We're creating fun and simple e-mail & calendaring software. We want our inboxes to be usable again: e-mail should be a useful tool, not a productivity killer. We want to be able to use our calendars to organise our lives, and we want other people to be able to interact with us through it whether they use Bongo or not.

=== Sounds good? ===

You're welcome to download Bongo, try it out, let us know what you think. We'd like you to get more involved, though! We welcome all feedback, and you don't need to be able to hack on code to talk to us.

We have an [[FAQ]], of course, and a guide on how to [[installation|install]] - then you can find out about [[Getting Involved|getting involved]] and how to become part of the community!
</div>

<div class="split-half" style="width:25%">
{{Planet}}
</div>
</div>

Releases/0.3.0-blockers

Alexhudson — Fri, 12 Oct 2007 08:28:57 GMT

Summary: /* Accepted blockers */

== M3 Release blockers ==

=== Accepted blockers ===

Please don't move stuff to this list unless you were given permission by so_solid_moo :)

* bongocollector segfaults [FIXED]
* hawkeye must be useful, get rid of the Javascript
* backup configuration set should be possible
* bongo-config should be scriptable and/or load backup sets
* bongosmtp dies with 'threads outstanding' messages
* e-mail bounces get eaten (confirm? may be fixed)
* dragonfly doesn't handle attachments well (#10247)
* antivirus configuration isn't right (#10239)
* zero-byte files in bongo queue (#10009)

=== Proposed blockers ===

* bongocalcmd cannot connect to the queue
* running under Apache requires certain files to be apache-readable
* logging in key agents

Releases/0.3.0

Alexhudson — Fri, 12 Oct 2007 08:25:48 GMT

Summary: /* Bongo M3 (0.3.0) Release notes */

__NOTOC__

= Bongo M3 (0.3.0) Release notes =

'''Further updates: 0.3.1'''

This release has received a minor update, and you are advised to use that version instead of the original. These notes still apply, but the links to download have been updated.

<div class="warning-alpha" style="margin-top: 15px;">
Bongo is currently alpha-quality software. It is under active development and is not yet ready for production servers.

However, we encourage you to try it out in a test environment and let us know what you think!
</div>

== About Bongo ==

Bongo is a project to create fun and simple mail & calendaring software. As well as providing a well-featured but extensible set of server software, it also comes with a user-friendly web interface.

Although Bongo is a young project, the software itself has a long pedigree going back to commercial products many years old. The core code isn't new, but the ideas we have and the direction we're taking are: we aim to provide a compelling alternative to other systems out there, not to compete directly with them.

We have a roadmap laid out to our 1.0 release, which we hope will appeal primarily to people who are interested in features which make email and calendars more useful, rather than those interested in "groupware" or "enterprise communication platforms". We're particularly aiming 1.0 at power home users, small organisations/businesses, and people providing mail services for third parties.

== What's In This Release? ==

This is the third release on the Bongo roadmap. As a source-only release, it is intended only for developers and advanced users who understand they will probably experience bugs and/or rough edges. Originally, we had planned this to be a release that end-users could effectively test: however, we've done an awful lot since M2. So, this release will be a developer only release, and the next will be a more formal alpha release.

M3 represents a huge amount of work done over our M2 release, and provides a working e-mail and calendaring system, the web user interface for e-mail and calendaring, and a web administration system. There are basic command line tools available to configure the system.

== What's New? ==

The headline features in this release are:

* localisation/internationalisation
* builds on a wider range of distributions
* configuration now based in Store, and not dependent on a custom LDAP setup
* proper syslog logging
* a powerful mail address aliasing/rewriting system
* support for multiple domains and hosted user accounts
* new, more performant, disk storage system
* initial support for CalDAV
* wider range of administrative tools for configuration, backup and restore

There are numerous under-the-bonnet changes which will interest developers listed above. We have simplified the system for loading configuration, and have completely reworked several structural parts of Bongo.

== Download and installation ==

You can download the M3 release from the GNA download page:

http://download.gna.org/bongo/release/bongo-0.3.1.tar.bz2

As a quick start, you once you've downloaded the release, you then:

tar -jxf bongo-0.3.1.tar.bz2
cd bongo-0.3.1
./configure --prefix=/usr/local/bongo
make
(as root from here)
make install
cd /usr/local/bongo
./sbin/bongo-config install

We have instructions for compilation in our [[Installation/Source | source guide]] - you will need to fulfill various dependencies, but they are mostly pretty simple.

After you have compiled and installed, you can then set about [[Configuration/Bongo | configuring Bongo]].

Binary packages of Bongo are also being made available on an ongoing basis, but remember that this is a developer release.

== Known Issues ==

You may want to review the project bugs page to see a complete list of those issues discovered. At the time of release, the following bugs are known:

* (major) the Dragonfly web UI is unreliable and buggy for many users
* e-mails without a subject may be incorrectly grouped into a single conversation
* some mail headers are sometimes incorrectly parsed.
* we recommend not installing to system locations (e.g., /usr), as our CLucene library will conflict with an installed version
* the web interfaces expect to be on their own domain, and the URLs cannot be configured to be different places
* running under Apache currently requires some work-arounds for file permission issues
* there are generic problems with bounce mail handling

Because of the large number of changes in this release, we expect that there may be several bugs which will bite people testing M3. We do intend to support tester/developers with this release, and will actively maintain this branch of the software, though.

== Next Release ==

As a supported branch of Bongo, M3 will receive minor updates, and in due course we will make further releases for those people trying to use it in practice.

The next major release will be M4. Coming in that release:

* new, more reliable, web UI for mail and calendar
* complete Hawkeye web UI for administration
* server-side rules support
* support for shared calendars/address books

There will also be numerous technical advances and bugfixes that may not immediately visible to users.

This will be our first preview release: we will be asking non-developers to try this software for the first time, and we think it will be mostly feature-complete. As such, there will be fewer new features in M4 compared to M3, but hopefully a lot more stability and reliability. M4 will only be released when we're happy it's useful for people to test, but we are aiming for April.

For further information, see the [[Roadmap]].

Development/Design/Flasher/Calendar Sharing

Halex — Sun, 07 Oct 2007 00:47:38 GMT

Summary:

== Calendar Sharing Storyboard ==

Bongo users will probably also want to share their calendar(s) with other people, some of whom ''may'' be running Bongo. They will probably want to do this so other people can give people permanent updates as to what they're up to, their status, or simply to aid event organisation.

'''Note:''' the images and stuff I've got on here aren't really storyboards as such, sadly. However, as example images, they '''do not in any way represent what the final product should look like'''!

=== Use Cases ===

# Lukas often needs to have meetings with his co-workers. By viewing his co-workers' shared calendars, he can work out when the best time to have a meeting is, by checking who will be available at what time, and if not, what they are doing (ie if Lukas can see Harry is doing a relatively non-important task at that time, and the time fits well with everybody else, Lukas might still want to have the meeting during that time period). Lukas will only be able to see events planned during work hours, which means that he won't be able to see what Sarah is up to later that evening.
# Jenny wants to organise something with a bunch of her friends, who aren't running Bongo. She has a quick look at her calendar to see what her best friends are up to, and notices two are going to a party the weekend after. Jenny clicks on the party event, and clicks 'Join'. She types in a quick message requesting if she can come. Jenny also adds her other friends to the invitation request, and clicks OK. A preformatted email is sent to the event organiser, who isn't running Bongo either, and she/he clicks on the 'accept' link, which brings up Flasher. Jenny receives a response a bit later, and the event now appears on her calendar, with the current attendees. Too similar to RSVP?

We would want the ability to share calendars so that the above use cases aren't completely fictional. This should be done by being able to click on a calendar that you currently own, and simply selecting Share. You should then be able to select who you share/don't share the calendar with, what times are viewable, and whether or not it requires a password to view.

Viewing shared calendars from within Flasher (not ICS-shared calendars) will probably involve just using a read-only version of the Bongo calendar interface, which may or may not be based on Flasher itself.

=== Sharing a calendar ===

[[Image:sharing-calendar-flasher.png]]

=== Viewing shared events ===

Probably just a read-only version of the Bongo calendaring interface.

=== Joining somebody else's event ===

[[Image:Calendar-sharing-joining-event.jpg]]

If the user doesn't have Bongo, they see the following in their Inbox, asking them to login to Flasher and accept/decline the request:

[[Image:Calendar-sharing-joining-event-emailreq.png]]

As per the RSVP page, we probably need some login hash in the URL or something.

=== Other screens ===

* How would we summarise what's happening; which invites do you have, etc? Would we have this as a separate bar? Is this even Flasher material?

=== Ideas up for discussion ===

* Is there really a need for the ability to edit others' calendars from within the interface itself? When sharing, I guess we can make it accessible from CalDAV, if necessary - I only really see this as being useful if you're working mobile, and need to edit your events without having to go into Flasher (eg using your desktop thick-client application, or using your mobile device such as a Blackberry, etc)

Development/Design/Flasher/RSVP

Alexhudson — Sat, 06 Oct 2007 14:39:46 GMT

Summary: New page: == RSVP Storyboard== Bongo users will want to use Bongo to arrange meetings, parties, or other types of event. To do this, they will need to contact people who don't use Bongo. We want Bo...

== RSVP Storyboard==

Bongo users will want to use Bongo to arrange meetings, parties, or other types of event. To do this, they will need to contact people who don't use Bongo. We want Bongo to offer these external people useful features so that it eases the life of the Bongo user in arranging the event.

=== Use cases ===

# Adrian is holding a party, and wants to invite his friends, who are all using e-mail. From within Bongo, he sets up the event and sends an invitation e-mail to his friends. The e-mail contains the link to Flasher. He wants his friends to be able to mark on his calendar whether or not they are able to come, and also would like Flasher to offer his friends useful features: e.g., a printable invite with all the information on it, perhaps a link to Google Maps, and the ability to invite other people Adrian originally missed.
# Adrian also wants to meet up with some old friends for dinner. He doesn't know what their schedule is, though, so sends them an e-mail asking them to let him know when they are free. They will then be able to access Flasher and mark the days that they are free, so Adrian can attempt to find a time when everyone is available. After a date has been found, they will all be sent a full invitation e-mail, but this time with RSVP pre-set to whatever they marked their availability as being (as that may change later).

In all cases, Flasher presents basically a single page which has all the event information on it. Users interact with the page, and can bookmark it.

=== Main RSVP ===

[[Image:Flasher-Storyboard-RSVP.png]]

=== Arrange a time ===

[[Image:Flasher-Storyboard-arrange.png]]

=== Possible other screens ===

Where privacy has been set on a page, we may need an authentication page before those two screens. Possibilities include:

* protecting the event with a single password;
* allowing contacts to login via OpenID;
* allowing contacts to e-mail themselves a login link.

In general, the login token should probably be encoded in the URL. The downside here is that we can't really authenticate individual users, just those who have been given access to the page. That's likely good enough though: we assume these people are probably friends :)

=== Open features ===

Some things I thought about, but didn't build into the screens:

* being able to invite others. We might say on the invitation that people are free to bring partners or even other friends we don't know, we should have a box where someone can put in an e-mail address and forward an invitation to that person. Problem here is spam potential.

Development/Design/Flasher/Rationale

Alexhudson — Sat, 06 Oct 2007 14:27:47 GMT

Summary: [[Development/Design/Flasher/Rationale]] moved to [[Flasher]]: Yay, more wiki like.

== What is Flasher? ==

Flasher is the web GUI that we make available to users who aren't on the Bongo system. We want to be able to interact with them, share events etc., without having to register them.

Primarily, people will gain access to Flasher in two ways: either by having a link sent to them via e-mail (e.g., an invitation), or by following a link from a website.

Flasher will not offer the same features as Dragonfly; Flasher users will tend to be inexperienced with Bongo and will not have time to "learn" the software - they may only ever use it once.

Flasher will be designed with specific use cases in mind, and will allow people to perform specific tasks.

Glossary

Alexhudson — Wed, 19 Sep 2007 21:26:31 GMT

Summary:

__NOTOC__

==== Agent ====

A standalone piece of software in Bongo, similar to a Unix daemon. Agents in Bongo tend to be very specialised and light-weight compared to their Unix counterparts: for example, a Unix MTA may speak SMTP, run a mail queue and deliver mail. In Bongo, that is separated into three separate agents.

==== Dragonfly ====

The web user interface for mail and calendaring.
Also known as "DF".

==== Hawkeye ====

The web user interface for administration and configuration.
Also known as "HE".

==== MDB ====

The initial releases of Bongo used a system called MDB to authenticate users, store software configuration, and for other tasks. This is now removed, but may still be referred to in places.

==== NMAP ====

An old name for the protocol that Bongo used to speak. NMAP is still referred to in the documentation and code in places. What was NMAP is now split between two separate agents, the Store and Queue.

==== Ninja ====

Ninja is a experimental store alternative for Bongo. It is also destined to be used to test Bongo's flexibility regarding modularisation, as well as testing both the official implementation and Ninja for bugs.

==== Flasher ====

A web calendaring interface for non-Bongo users.

==== Crystal ====

Codename for what will become the new modular web interface for Bongo users. It will include modules for mail and calendaring, primarily.

Dragonfly Technical Stuff

Alexhudson — Wed, 19 Sep 2007 21:13:30 GMT

Summary: New page: Various technical issues with the current Dragonfly implementation. Where sizes are mentioned, I've tried to ascertain the correct size for what we use, but may be mistaken (it may be we d...

Various technical issues with the current Dragonfly implementation. Where sizes are mentioned, I've tried to ascertain the correct size for what we use, but may be mistaken (it may be we don't use an entire library, or for some other reason I got the size wrong ;)

== Concerns ==

# Size! 'Packed' final.js is 560Kb. We need to be a much lighter download by default; the core needs to be under 100K really. And we haven't really implemented contacts and other important features.
# Related to size, speed - login speed now much better that it was, but still room for improvement.
# Reliance on a number of external libraries: prototype (80Kb), script.aculo.us (200Kb?!), and MochiKit (120Kb packed). Adds to our size (400Kb in total?), probably making up at least 60% of our size. Many of these libraries do much of the same thing.
# Riffing on size still: many people will want to access their mail over https. This limits cacheability. Dragonfly needs to be usable accessing it remotely over a slow connection (100Kbps-1 up?) over https, as a target. Usable doesn't mean "amazing", but live-able.
# Concern on the manageability of these dependencies going forward. Will they continue to be developed (Mochi and script.* both seem to be slowing at best), and be compatible (e.g., $ ownership)? Is this sustainable, and will browser compatibility suffer?
# Failure modes are silent and often killer. Can we at least detect errors and let the user know something bad has happened?
# Mail processing happens on the client side; wasteful. Client side shouldn't need to know about formats / character sets / MIME etc., that should all happen server-side.
# Builds a lot of HTML in the code, not wonderful.
# Current src/www/ is very dragonfly-oriented, not terribly well separated.

== Future stuff we want ==

# We want to be able to have 3rd party plugins. If the core isn't fast, core + plugins will be horrific.
# Some pieces aren't terribly well separated. Makes it difficult to have a consistent plugin architecture. Perhaps the core should be built from default plugins.
# Flasher should be buildable out of the same pieces as dragonfly. Maybe flasher is dragonfly, maybe not... ?
# We have vague l10n, but not i18n. Particularly not RTL and script languages.
# How on earth do we i18n calcmd? Maybe forget about it for now?

Guides/Webserver Optimisation

Halex — Tue, 14 Aug 2007 07:35:42 GMT

Summary: /* Apache */

{{stub}}

A few pointers:
* Setup ETags;
* Add an expires header; and most importantly,
* '''GZip components!'''

=== Apache ===

Apache2: Install mod_deflate and you should be good to go. Make sure the mimetype is setup for .css and .js
Apache: Install mod_gzip and setup mimetypes if necessary

FIXME: Expand this, a lot.

Development/Design/ImportExport/Addressbook

Forcev — Thu, 02 Aug 2007 17:16:21 GMT

Summary: /* Implementation Ideas */

== Overview ==

Being an e-Mail/Calendaring application, Bongo needs to be able to store and share contact information for users. The idea is to allow users the ability to share their contacts using the most common and accepted formats. To date the main ones appear to be VCF, LDIF and CSV.

=== Basic Ideas ===

By using the above formats we should be able to share contacts with the majority of desktop clients on all platforms - Thunderbird, Outlook, Evolution, Outlook Express and Claws-Mail being the initial focus.

Initially we need an export of each client's supported format, but only if it is complete e.g., if Outlook exports csv and ldif, but the ldif doesn't have all the info of the contacts, then we don't care too much for it's ldif support. This way each client should have at least one supported format.

=== Supported formats by clients ===

{| class="client-format"
!Client
!Import Format
!Export Format
|-
|class="yes"| [http://www.mozilla.com/thunderbird/ Thunderbird]
|class="planned"| LDIF, TAB, CSV, TXT
|class="planned"| LDIF
|-
|class="yes"| [http://www.gnome.org/projects/evolution/ Evolution]
|class="planned"| LDIF, TAB, CSV, VCF
|class="planned"| NONE
|-
|class="yes"| [http://www.claws-mail.org/ Claws-Mail]
|class="planned"| LDIF, MUTT, PINE
|class="planned"| LDIF, HTML
|-
|class="yes"| [http://www.microsoft.com/outlook/ Outlook]
|class="planned"| WAB, TAB, CSV, VCF, PST
|class="planned"| NONE
|-
|class="yes"| [http://www.microsoft.com/windows/oe/ Outlook Express]
|class="planned"| LDIF, WAB, CSV, VCF, TXT, PST
|class="planned"| WAB, VCF, TXT, PST
|}

=== Implementation Ideas ===

Initially all import/export work is done via the commandline with <tt>bongostore-tool</tt>, but hopefully a Dragonfly interface will enable users to do it in a friendly environment. There will need to be several options with little hints so users know which file type is best to use:
* If exporting to Thunderbird, please select LDIF or CSV formats.
* If importing from Outlook Express, please select CSV or VCF.

=== Complexity ===

One of the biggest problems is that each of the clients handle the fields of a contact differently on an import and export. This leads to garbled contact information when moving contacts from client<-->client or even client<-->bongo.

Documentation/Administration Guide/User Creation

Lhaig — Sat, 21 Jul 2007 19:21:26 GMT

Summary: New page: =Creating your own users= <pre>(a) Login to the server (b) Enter the following command to create a user bongo-admin ua <username> --given=<FirstName> --surname=<LastName> and hit...

=Creating your own users=
<pre>(a) Login to the server
(b) Enter the following command to create a user
bongo-admin ua <username> --given=<FirstName> --surname=<LastName>
and hit return
(c) Enter the admin password you set earlier
(d) bongo-admin up <username>
(e) Enter the admin password you set earlier
you should get a response saying added user:
(f) If you want to know more about the bongo-admin functions enter/
bongo-admin on its own and hit return. this will produce a list of/
options.
</pre>

Development/Design/Dragonfly/Plugins

Alexhudson — Sat, 21 Jul 2007 14:18:08 GMT

Summary: New page: == Plugin Overview == Dragonfly, being web-based, needs to be as slim as possible in order to maximise speed and stability. However, users demand crack, so to fulfil some wishes, the idea...

== Plugin Overview ==

Dragonfly, being web-based, needs to be as slim as possible in order to maximise speed and stability. However, users demand crack, so to fulfil some wishes, the idea is to allow extra features to be inserted as plugin. This system would be designed to make most things possible in some way, not to allow users to alter absolutely everything.

=== Basic Ideas ===

Key parts of the user interface will effectively be built by the plugin management system. They would include:

* the navigation bar on the left
* horizontal tool bars
* popup boubles
* maybe the small links at the top-left
* ability to provide complete new views

Plugins would be able to place bespoke UI in those widgets mentioned.

=== Implementation Idea ===

The user will be able to turn plugins and and off, from a server-provided list. Plugins will be loaded in order, and the user can set that order - that would control the order of widgets in the UI.

Plugins will provide the system with a JSON structure describing them, and what they provide. So, for example, if a plugin provides navigation bar UI, this would happen:

* Dragonfly loads the plugin into it's system effectively as a single object;
* Dragonfly asks for its description, and sees it provides nav bar UI;
* the description points at an object method, and Dragonfly constructs an array holding all the methods which want to provide navbar UI;
* when constructing the nav bar, Dragonfly calls each object method in order, and they return a DOM object which is appended to the nav bar

In more detail, it seems that we have a need for some standard views: mail view, calendar view, etc., and we would ship default plugins to handle those. Perhaps we would allow them to be overridden, though, or missing entirely.

=== Complexity ===

* How could/should this interact with zones? Should plugins be zone aware? Can they setup zones?
* Plugins cannot depend on other non-standard plugins, for now. That makes it too complex.
* Plugin order would dictate position in UI. If the plugin provides navbar and toolbar UI, you can't have the navbar UI come last and the toolbar first. Tough.

=== Outstanding Questions ===

What framework do we need to provide to plugins? Ideally, we'd maintain Dragonfly as a framework plus a set of plugins, so we'd have:

* Dragonfly UI framework, which understands plugins,
* Dragonfly plugin manager, to load the plugins,
* various helpful libraries in a common API: e.g., JSON, effects, server protocol, etc.

The various helpful libraries need to be broad enough to allow different types of plugin, and encompass common needs, but not too broad: in general, it would be better to offload work to the server and have more brains over there, and keep the Javascript slim.

=== Use Case Personas ===

Here are a few personas outlining use cases that we want to make work, and are the raison d'etre for all this extra effort. If you can think of other ones, add them, and at some point we'll pick the three or four which make most sense.

==== Brian, the small business IT administrator ====

Brian already has a successful IT setup, which includes mail. However, his users are demanding calendaring sharing features, and he wants to use Bongo in that capacity. He might be willing to migrate to Bongo at a later date to get better integration, but for now he wants to stick with his current mail system and offer web-based calendaring. He'd like to be able to remove the mail and contacts UI parts for now, and have simply the calendaring experience. With the extra space on the summary page, Brian wonders if he can offer users more information there - perhaps a local weather summary, an RSS feed of company news, and links to the intranet.

==== Joe, the third-party developer ====

Joe offers a web-based document management system, which is great at managing content, but doesn't have many workflow features. Users are asking if they can integrate it into their calendaring systems, and Joe would like to offer something for Bongo. He thinks it would be nice to be able to summarise recently edited documents for users, and also link documents into events - for example, deadlines. To do this, he envisages a summary view widget that displays recent documents, and a widget in event pop-ups to which to the user can add document references.

==== Paula, the Bongo community member ====

As a community member, Paula often sees people come into the chat room asking if Bongo has such-and-such feature in the web UI. She decides that she'd like to try her hand at creating a plugin for some of the better ideas she sees, and she knows a little about how Bongo works already.

Development/Design/Dragonfly/PluginIdeas

Alexhudson — Sat, 21 Jul 2007 09:32:21 GMT

Summary: New page: == Plugin Ideas == This is a list of potential ideas that we might want to implement as plugins. This is drawn from existing functionality, functions other people have, etc. This should h...

== Plugin Ideas ==

This is a list of potential ideas that we might want to implement as plugins. This is drawn from existing functionality, functions other people have, etc. This should help us design a plugin system which can meet many, but not all, needs.

=== Bongo Plugins ===

==== Rules control ====

We could ship two rules controls, a simple one and an advanced one. The simple one might be:
* ability to click on a sender and select "Create rule.." to create a rule based on that sender;
* a prefs window to create a simple linear list of rules, with simple conditions and results;

The advanced one could extend this by adding support for more complex rules within the prefs window (which it effectively re-implements), allowing e.g., ability to filter by mail header, or regex, or something.

==== Sync control ====

Some kind of control to synchronise content to a PDA/etc. Would consist of:
* a navbar control to initiate a sync;
* possibly some kind of prefs panel to configure the sync.

=== Mail Plugins ===

==== Starred mail ====

The ability to star conversations, already in Dragonfly, could/should be a plugin. This consists of:
* a star against conversations in a list;
* a toolbar control to star/unstar in mail list view and conversation view

==== Tags ====

The ability to tag mail with keywords. Not totally sure how this might work, but maybe:
* a toolbar control in mail list and conversation view to add tags, maybe based on a drop down, or text entry control, or combination;
* a navigation bar tag cloud, possibly, to present a mail view filtered by tag;
* a search filter, possibly, to filter a search by tag (or not tag);

==== Avatar support ====

The ability to put avatars into mail views. This would consist of:
* putting the user's picture in the conversation view (based on the picture held for them by Bongo);
* new button in Contact bouble to allow the user to look for Gravatar pictures, etc., and set them on the contact;
* perhaps something which looks at mail headers for avatar info?

==== Composer ====

Our composer will likely not suit everyone. We could offer the ability to replace it.

==== Spam support ====

The ability to mark mail as spam/not spam, and potentially train a server-side filter based on that. This would consist of:
* an icon in the mail view signifying whether or not the mail was spam;
* toolbar buttons to mark as spam / not spam;

==== Mail proxy support ====

A prefs dialog to setup mail proxy settings. This would be a plugin so that admins could remove it, preventing users setting up mail proxies directly.

==== RSS Feeds ====

Ability to consume RSS/Atom and put a small overview on the summary page, plus a full feed view

=== Calendar Plugins ===

?

Development/Design

Alexhudson — Sat, 21 Jul 2007 09:06:29 GMT

Summary:

__NOTOC__

== Flasher Design ==

* [[Flasher | What is Flasher?]]
* [[Development/Design/Flasher/RSVP | RSVP Storyboard]]
* [[Development/Design/Flasher/Calendar Sharing | Calendar Sharing]]

== Dragonfly Plugin Architecture ==

* [[Development/Design/Dragonfly/Plugins | Plugin Overview]]
* [[Development/Design/Dragonfly/PluginIdeas | Plugin Ideas]]

== Import/Export ==

* [[Development/Design/ImportExport/Addressbook | Importing/Exporting the addressbook]]

== Agents ==

* [[Development/Design/Agents/AgentIdeas | Ideas for Agents]]

Bongo Love/Import mail into folders

Alexhudson — Thu, 19 Jul 2007 20:15:12 GMT

Summary: /* Import mail into folders */

Development/Wishlist

Alexhudson — Thu, 19 Jul 2007 19:28:29 GMT

Summary: /* Dragonfly */

== Wishlist ==

What things should we consider developing on bongo?



=== Rules Agent ===
* Should be rewritten to allow users to set their own rules without needing to enter the admin ui.

=== SMTP Agent ===
* Support for antispam mechanisms which require training, such as DSPAM, CRM114, etc.
* Support chained certs (usually catted together in the same file)

=== IMAP Agent ===
* Support chained certs (usually catted together in the same file)

=== POP Agent ===
* Support chained certs (usually catted together in the same file)

Documentation/Administration Guide/USer Creation

Lhaig — Thu, 19 Jul 2007 16:09:44 GMT

Summary: /* Creating your own users */