[Agendaware-dev-server] [Fwd: XML Defs]

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

Good thinking Shane.  The xml doc I posted is really just a starting
point.

Like you suggest we should start on the api.  One big decision with that
is whether the communication should be 2 way or whether it should all be
client initiated.  I think it would be good to let the server notify the
client instantly if new mail comes in.  Once I started thinking about
the ramifications of that (listener on the client side, much more code
to write, complexity) I went back to the idea of having it all client
initiated, to keep it simple and manageable.  Is everyone in agreement
there?

If we start with 1 component, it should definitely be email.  I think
the last one should be IM, as it is very different from the other 2
(communications-wise, I think a mail msg and calendar msg should be
treated the same, unless we think of a good reason why not).  On IM, I
had a look at some jabber stuff.  There is a Jabber applet client
released under an OSI type license called JOSL.  You can modify as long
as you contribute changes back to jabber.  It might be worthwhile for us
to just port the applet to an application, and insert it our client. 
Someone could even work on that very independantly. 

The basic idea I had with the client was that it should keep a data
store of everything locally, so that we support off line workers, and
for response time.  The definitive copy of everything will of course be
in the database, and the client and server will focus on keeping the
local desktop synced as well as possible.  In addition, everything
having to do with the client that is not workstation specific, should be
stored in the database, so a user can roam from 1 workstation to another
(this includes inbox folder info, personal address books, language
etc).  Other things like window size/placement preferences will be kept
only on the client workstation.  So with that in mind, here is some of
the functionality I tink we will have to accomodate.  Everyone please
add/ammend anything you see and send back to the list.

Login
Logout
Get User Preferences
Set User Preferences
Get Message Changes - New/edited messages (at this point a message can
be a mail message or a calendar message)
Get Specific Message - In case the is an error on the client, it might
want a single message
Send Message - new or edited
Delete Message
Get Attachment - How do we deal with attachments?  Everything else is
xml...
Get Directory Changes - New or edited
Get Directory Entry
Send Directory Entry   - Update contact info per security restrictions
(self in public, all in private address book)
Delete Directory Entry - again, per security
Check Schedule/Free Time - For scheduling meetings

One way to deal with keeping sync is every update (server response to
Get Messages/Get Directory/ Get User Preferences) the server gives the
client a timestamp (no problems with clients clocks off).  The client
stores that time stamp, and when the client asks for an update, it sends
the last timestamp it got from the server.  If something happens on the
client end (new client install, lost local database, roaming user) the
timestamp will default to 0 seconds from epoch, and the client will
automatically get all their info.

I think that this whole design is going to be database intensive.  That
is one reason why the local database (in memory with long term
persistence in xml file(s)) makes sense, as the client will get good
response.  On the other hand, just with constant polling and small
updates, the server and db are going to be working pretty hard.  It will
be important for us to use good design.  Obviously we will need quite a
few tables (I am thinking each user will have a personal inbox table, a
personal directory table, as well as a user preference table, then there
will be the main databasae table for messages).  As for the main table,
there might be some things we can do to help that out.  Clearly there
will need to be a table to relate attachment files.  We might even want
to relate the message body to a file outside of the database.  We also
might want to look into archiving older emails into other tables, maybe
per month or something, to keep the main table a little lighter and
quicker.  But I digress....

Am I missing anything on the functionality?

Zack


 

-------- Original Message --------
Subject: XML Defs
Date: Thu, 8 Nov 2001 12:31:56 -0800 (PST)
From: Shane Turner <tur...@ya...>
To: zack <za...@th...>,
age...@li...

Zack,
I noticed where you posted some ideas about the XML
APIs to the be used and I had a suggestion. The root
elements you have are a good place to start, but I
thought it may be clearer if above those elements we
had a tag of something like "Request" and "Reply" to
identify the type of communication this is. For
example, on the server side, if server to server
communication is happening, the server will need to
know if the incoming XML is a request for information
or a reply to a previously sent request.  The client
will only receive "Reply" XML docs, but I think these
tags make the communication (at least when viewed by
an XML viewer or something during testing/debugging) a
bit clearer what is actually happening. 

I think the best thing to do at this point is to get
the API down first.  Once we determine the calls that
can be made back and forth between the client and
server, we can then start designing/coding the server
and client to handle those requests and work
independently.  I'll start looking at the XML doc you
started and try to really define the kind
queries/responses/calls that need to be made between
the client and server.  

Just for simplicity, is there any particular component
you would like to look at first (email,calendar,im,
etc. . )?  I think email would be the logical start
since that's sort of the basis for this whole thing.

Anybody else have any thoughts?


__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com