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

[Zack L. <zl...@no...>]

Comments inline...

ZL


From: Shane Turner <tur...@ya...>
>Subject: Re: [Agendaware-dev-server] [Fwd: XML Defs]
>To: zack <za...@th...>,
>   agenda-server <age...@li...>,
>   Agenda-client <age...@li...>
>In-Reply-To: <3BE...@th...>
>MIME-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>
>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.

Agreed.


>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.

Yeah, I thought the way to handle that on the client side is that the gui 
components only write to the local db mgr.  The comm component can check on 
launch and periodically and just keep a variable set whether online or 
offline (or even degraded for slow or spotty links).  The local database 
mgr just checks that variable and decides whether to pipe to comms, or to 
local xml file.  This should keep the gui and the store from wasting any 
time, and the comms piece will run in a different thread, so if it is 
waiting for a timeout or something, nobody will notice.



>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.


Cool.


>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.

Sounds good.


>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.

That is exactly what I was thinking.  Folders should be virtual.  It will 
just be another property of the msg.  That way, a user can display their 
inbox by folder, or by thread or sender or whatever, and for certain 
displaying (like by sender), you might not want to be limited to physical 
folders.  Currently, I can sort my email folders by sender, but only in the 
current folder.  That is no good when I set up some sub folders by sender, 
and some by project.  And if you want to view msgs by thread, having them 
in separate physical folders would be a nightmare.  So, I would like to put 
forth the idea of inbox "Views" just to standardize on terminology.  The 
View can be by folder, by sender, by project, by type (todo, fyi etc), by 
thread or whatever.  These views will then be sorted by other factors like 
date/time or whatever.

 From the database perspective, I think each msg should have a single 
instance in the main msg table.  Each user should then have their own inbox 
table


>--- 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