[Agendaware-dev-server] Re: Agendaware Document

[zack <za...@th...>]

Shane,

Good going.  I think we are definitely on the same page on most
issues.   I went ahead and added you to the project.  Currently in CVS
there are 3 modules defined: client, server and db.  I will write some
of my thoughts inline with your doc below.

Also, I set up some mailing lists on
sourceforge.net/projects/agendaware, this should make it easier for us
all to communicate.  The other guy is Rahul, he is concentrating on the
server side also, whereas I am concentrating on the client side.  There
is also a woman named Saritha who is interested in joining, who has
strong database skills, as well as c++.  I am also trying to enlist some
java expertise to help me on the client side.

So again, I think we are all very close here.  We should just come
together on some of the outstanding points like IM, database,
calendaring standard.  Drill a bit more in depth on this.  Then I think
one of the crucial aspects will be to set the client/server api.  Once
that is done, it makes th client and server projects a bit more
autonomous, as we will all have somthing to write to.

Zack

PS - Rahul/Sarith, have a look at this and tell us what you think.


Shane Turner wrote:
> 
> Well, I got around this weekend to putting together a
> few ideas that I had about how to implement the server
> side of Agendaware.  It's not much, but it's a rough
> draft. I wanted to send this doc to you to go over and
> see if it represents what direction you would like to
> see this project go (and to see if we're on the same
> page in our thinking).  Just give it a quick look.  If
> you have any suggestions, questions or just general
> comments, just drop me a line and we'll discuss it.
> If you like it, I would like to start posting them
> into the CVS storage as reference docs.  My id at
> sourceforge is turne016.  I also noticed another
> person had joined the project.
> 
> I have started looking at a general outline
> of the software architecture for the server.
> I'll be trying to put this together in the next
> week or two.
> 
> Thanks!
> Shane
> 
> __________________________________________________
> Do You Yahoo!?
> Find a job, post your resume.
> http://careers.yahoo.com
> 
>   ------------------------------------------------------------------------
> The main purpose of this document is to try to create an initial
> design for the creation of a groupware server for Linux.  The
> main goals for this project are a fast, scalable, fully functioning
> groupware server that can support any size of business and any number
> of users, from small business to the enterprise.
> 
> 1.  Server Functionality
> 
> The groupware server will provide basic groupware functions for the standard user
> in the computing environment.  These include calendaring, instant messaging, directory
> services and email.
> 
>     A.  Calendaring
> 
>     Basic calendaring functionality is essential in the work environment.
>     The scheduling of meetings, to do lists, free time, busy time all need to be
>     available to insure the flow of information and scheduling between many people.
> 
>     The calendaring option proposed is one based on the iCalendar standard proposed
>     in RFCs 2445, 2446 and 2447.  This standard provides a rich set of
>     ways to exachange information regarding calendaring information.
>     A few of the things provided are meeting/event scheduling and invitations,
>     "to-do" entries and scheduling busy-time or free-time.
> 
>     For the purposes of the server, the iCalendar standard will be encompasssed
>     in an XML form that can be exchanged between the client application
>     and the groupware server.
> 
>     Each user on the system will have a personal calendar
>     as well as access to public and/or global calendars.  Global or public calendars
>     provide a calendar to provide information to a common group or department.
>     For example, the sales department will have a common "Sales" calendar that
>     contains information related to events occurring in the Sales department.
>     Also people may have access to others calendars if the owner grants the
>     appropriate permissions.  This would assist in instances where an assisant
>     schedules appointments for his/her supervisor.  The supervisor would give
>     the assistant read/write access to his/her calendar so the assistant
>     could schedule events for the supervisor.

Only comments here are whether we should actually follow the iCalendar
standard.  I haven't looked at that standard, but my concerns are...
If possible, I would like to treat messages, calendar events, tasks etc,
in the same manner.  The iCalendar might not be compatible with our own
standard for other types.
We might need other elements in the calendar xml object, like rights
(who can read, who can edit etc) an item, or automated features like
meeting rooms which might have their own calendar, but would need
automation, or any other myriad of differences.
If the standard fits our needs, then great, otherwise we might have to
veer.


> 
>     B.  Directory Services
> 
>     Directory services provide a means to view and identify people in a common
>     organization or group.  Scalable directory services are a must for
>     large sets of users.  The proposed directory service is LDAP.
>     LDAP is chosen because of it's open standards and scalability.  Once
>     of the better known LDAP servers currently available is OpenLDAP (www.openldap.org).
> 
>     In the scheme of this design, the groupware server would provide a "proxy" to
>     the LDAP server, fulfilling client requests to search or find other users
>     in the system.  No direct access would be granted to the LDAP server.  All
>     LDAP requests would come through the groupware server.  With this design,
>     it also becomes possible to provide scalability.  In a smaller environment,
>     the groupware server and LDAP server may reside on the same machine and provide
>     adequate performance for the users.  In a large environment, it may be possible
>     to provide the groupware server on a box by itself and the LDAP server on another.
>     Aside from users and directory services being stored in the LDAP server, all
>     other information is stored in a database.

I agree 100%. 

> 
>     C. Instant Messaging
> 
>     Instant messaging is also an area that is extremely useful.  While email
>     in itself is almost instantaneous at times.  Many emails back and forth
>     trying to make up a conversation can be frustrating.  Instant messaging
>     is the answser to this.
> 
>     The server would provide the ability to allow one-to-one conversations, as
>     well as virtual chatrooms where many users can attend and see all messages
>     of other members, something similar to a virtual meeting.
>     Another idea may be the ability to record the conversations between two
>     people for reference.   This would be extremely useful inh the virtual
>     meeting scenario where recording the meeting conversations would
>     act as "meeting minutes" and could be referred to later.  Also one could
>     have a shared whiteboard available so that users could drawn and illustrate
>     ideas to the person with whom they're messaging.

Rahul and I have discussed this a bit, and thought that going jabber
compatible would be a good thing.  I don't know if it supports
whiteboard functionality or not, but it does add universal
connectivity.  We can discuss this some more.


> 
>     D.  Email
> 
>     Last but not least is email, the lifeblood of the modern computing environment.
>     The server would handle all internal email and be able to receive
>     any external email.  Internal email would also contain some added features
>     which is common in most groupware appications.  Enhanced features
>     may include special tags specific to the groupware application.
> 
I have a number of ideas on this that I think will really help people
use email more effectively.
1.  Addressing:  Instead of having a to:, cc: and bcc: lists, we can use
FYI:, TODO:, INFO REQ:, or other similar types of lists, so that when
the people actually receive them, they can be dealt with more
efficiently.  If you get an email with a TODO icon, you might deal with
it before reading an FYI.  This puts a tiny bit of a burden on the
sender, but helps the receiver.
2.  Tags:	Senders can tag emails with the normal tags, "importance" or
whatever, but also have a project or topic tag.  This will be used to
allow the reciever to sort/view/search messages/meetings/tasks by the
project. 
3.  Inbox:	Messages will not live physically in their sub folders.  That
will just be another tag.  A user can view their inbox by folders, but
can also view by project, by thread, by sender (currently, most email
clients you can only view by sender in the current directory), by
date/time, etc.  This can give people more effective ways to deal with
messages.
4.  Group mailboxes:  This can be a usenet type posting mailbox with
threaded messages (bulletin boards), or can also be for group work like
su...@ag... might be used by a whole support dept.

> 2.  Server Design and Architecture
> 
>     A.  Scalability
> 
>     The design of the server should be versatile enough to provide scalability.
>     Some things of consideration may be allowing a server to act as a
>     load balancing server between many other servers.  This would provide
>     maximum scalability in large enterprise environment.  The load balancing
>     server would handle all requests, but then redirect the client to an
>     available groupware server to handle his requests.  The load balancing
>     server could provide several different load balancing algorithms to choose
>     from based on a specific hardware/software environment.

Cool.  To go hand in hand with this, is to make sure we have the ability
to link domains.  For example, Server A (or Farm A) handles
dev.agendaware.com, Server B handles sales.agendaware.com, Server C
handles sales.agendaware.com.au.  Firstly, there should be a way to link
servers/domains.  Secondly, there should be a way to define which
address books, schedules etc, are exported or shared with other
domains.  Some might want full integration across domains, others might
want more autonomy (address book yes, calendars no).

> 
>     The next issue of scalability is the storage of information.  The LDAP
>     server has it's own storage, so the database design, both physical
>     and logical is essential to insuring scalability.  One idea is to separate
>     the information in to separate logical databases.  For example,
>     all email is stored on one, all calendaring information in another, etc...
>     In small environments, all would reside on one server, in larger, it may
>     be partitioned between machines.

Agreed.  Also, I think the server should have the master/definitive copy
of everything, but the clients should mirror that locally, so for
laptop/offline users, they can still write mail to queue for send,
schedule stuff etc.  The client can just write all the objects to an xml
file for long term persistence.  The client/server comms will focus on
just syncing changes to reduce bandwith needs and responsiveness.

> 
>     B.  Information Storage
> 
>     The storage of information will be stored in an RDBMS.
>     While initial versions of the server will provide open source
>     database implementations, it should be possible to plug in other
>     database systems with relative ease.  This should be possible
>     by providing a database abstraction layer such that using another
>     database is just providing the DB implementation layer of choice.
> 
>     C.  API
> 
>     The API for the server could be based on XML since it is now
>     a widely accepted standard and would provide easy creation of the
>     client.  However, the XML parsing may affect performance.  This
>     still may be an issue to be determined however.  If XML is used, it
>     would probably be preferred to use the simplest XML document possible
>     to provide quick parsing of the client request.

Definitely agree on using xml.  We have been thinking about using DOM
over an ssl stream for client/server comms.  While SAX might seem more
appropriate for stream based comms, I think DOM will let us express
messages/meetings etc more easily.  Also, using xml for config, long
term persistence etc, that makes sense too.