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

[Shane T. <tur...@ya...>]

I agree that it would be easier to have the client
initiate all communication.  A simple thread in the
background to request new updates shouldn't be
difficult.

I think the idea of offline stores for responsiveness
is a must.  For example, at work, we use Lotus notes. 
Notes has feature to adjust the client to indicate
where you are (on the lan, dialup, not-connected).  If
the user chose not-connected, the client could revert
to it's local copy, and queue any messages  for later
delivery/update. I also like the idea of storing
things locally (and keeping in sync of course) so that
the client doesn't drag.  Using Lotus notes, it seems
like everytime you hit a button, it makes a network
call (which is ridiculous in my opinion) and if the
network is slow or the server goes down, it just hangs
for 5-15 seconds and can be pretty annoying.  

I think at times, this design can be pretty DB
intensive, but that's just the nature of it, however
with caching on the client side and server side, I
think we can make it pretty efficient overall.  I have
posted a design on an initial server architecture that
outlines a few things related to performance (if you
haven't seen it already). I suggested a server side
cache to avoid pounding the db constantly as well as
connection caching to reduce db stress also.

I did a few searches on binary and xml (for handling
attachments).  It looks like a few suggest converting
to BASE64 before transmitting.  This seems like a good
way to start until we find a better way. 

One other addition, we should provide folders to group
the email by for the user.  When they receive a
message in the inbox, they may want to move it to a
folder named "Family" if it's from a relative, etc. .
.
Also, maybe the idea of "virtual" folder.  By this, I
mean that they can create a folder, however
technically the folder doesn't contain anything, it
really serves as a sorting method.  When they click
this folder, it simply resorts the messages based on
te preferences of the folder.  We can play around with
these ideas late though.

--- zack <za...@th...> wrote:
> 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
> 
> _______________________________________________
> Agendaware-dev-server mailing list
> Age...@li...
>
https://lists.sourceforge.net/lists/listinfo/agendaware-dev-server


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