agendaware-dev-server — Dev List for Server development

Re: [Agendaware-dev-server] XML APIs

[Hans F. <Han...@ho...>]

Hello,
I have a suggestion. Instead of using diffrent tags for all the diffr=
ent=20
information, we could use a type and action tag. It could look someth=
ing like=20
this.
<Agenda>
=09<Type>MailMessage</Type>
=09<Action>UpdateRequest</Action>
=A0 =A0 =A0 =A0 =A0 =A0 =09<Update> =A0 -- 1 or more mail message upd=
ate
=A0 =A0 =A0 =A0 =A0 =A0 =A0=09<Uid>kdsjf</Uid>
=A0 =A0 =A0 =A0 =A0 =A0=09=09<Attributes>laksdjf;lsdkjf</Attributes>
=A0 =A0 =A0 =A0 =A0=09</Update>
</Agenda>

This probably make it easier to add some filtering function both on t=
he=20
server and the client side. Instead of having to search for diffrent =
tags, we=20
could just take a look at the type tag and compare the value from it.=
=20

The downfall of this might be that it makes it harder/impossible to w=
rite=20
DTD:s that make sure that we don't mix types with data it doesn't sup=
port.=20

/Hans

On Sunday 11 November 2001 03:49, Shane Turner wrote:
> Sorry, got trigger happy and for got to attach it.
>
> --- Shane Turner <tur...@ya...> wrote:
> > Hey everyone, here's a rough outline of some
> > possible
> > XML API's.  These are samples for directory,email
> > and
> > admin access.  I'm sure there's a lot more to list,
> > so
> > send me any additions/suggestions and we'll try to
> > add/change them and get a working set to design
> > against.
> >
> > __________________________________________________
> > 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

----------------------------------------
Content-Type: text/plain; charset=3D"us-ascii"; name=3D"XML_DEFS_2.tx=
t"
Content-Transfer-Encoding: 7bit
Content-Description: XML_DEFS_2.txt
----------------------------------------

Re: [Agendaware-dev-server] XML APIs

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

Good catch on the SSL stuff, I didn't think about
having to construct a different connection for SSL vs
non-SSL. 

On the Admin interfaces, I assumed a separate client
for administration, I just figured that it would need
a set of XML interfaces as well.  I think a separate
admin client is better than integrating it with the
standard client (more security).

On the timestamp issue, seconds since epoch is easy
enough on server side.  We can timestamp each server
reply so we're all talking the same time.

I guess now I'll look at actually defining the
MailMessage, DirectoryEntry and incorporating the
comments you added.  Can you send some examples of
your idea of tags and such for sorting, etc. . .
?(Maybe an XML example). 


Group Question:
Does anybody have an IM account setup so that 
we could exchange ideas real time if we happen
to be online at the same time?
For example, I have an AOL instant messenger account.
Same as my email (turne016). 
 




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

[Agendaware-dev-server] Forgot something...

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

...on the xml specs.

I think we need a way to get and set user preferences.  This will help 
with roaming users in particular.

Client:
<RetrieveUserProfileReqest username="jack1">
</RetrieveUserProfileReqest>

Server:
<RetrieveUserProfileReply>
	<property ...>  (as many properties as we have)
	</property>
</RetrieveUserProfileReply>


Client:
<UpdateUserProfileReqest username="jack1">
	<property ...>  (as many properties as we have)
	</property>
</RetrieveUserProfileReqest>

Server:
<RetrieveUserProfileReply>
	<StatusMessage success="1">User ???'s profile updated</StatusMessage>
</RetrieveUserProfileReply>

Also, we could automatically send the UserProfile with the login 
successful msg, but still provide the above to functions in case needed.

Zack

Re: [Agendaware-dev-server] XML APIs

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

Good stuff Shane.

I bet anyone who is subscribed to both server and client mailing lists 
is starting to get tired of getting 2 copies of every email, but, it 
should only be this way in the beginning, as we are hashing out the 
comms side.  Once we get our protocol down, there should rarely be any 
duplicates.

Comments on the doc below...

ZL

> 
> 
> ------------------------------------------------------------------------
> 
> Below are listed the client server communication XML API's.
> Listed below are explanations of elements as well as sample
> communication that would be involved. The root element of all
> communication is <Agenda></Agenda>
> 
> 1.  Init
> 
>     Init is used to initialize communications between the server
>     and potential client.  This method may be used to set certain
>     communication settings before starting logon (such as whether to
>     use SSL).  The example below shows how to init a connection
>     with SSL turned off.  If settings are specified, the settings
>     (such as ssl) should be started on the next client request.
> 
>     Client:
>         <Agenda>
>             <InitConnectionSubmit ssl="0"/>   -- don't use ssl
>         </Agenda>
>     Server:
>         <Agenda>
>            <StatusMessage success="1"/>Initialization successful</StatusMessage> -- init successful
>         </Agenda>


How about using a non-ssl port and an ssl port?

 From the client side, if I send a msg saying the next client request 
will be ssl, I have to build a whole new connection to the server with 
ssl handshake etc.  Also, I don't know how it is in c++, but I don't 
think you could bind a server socket, and an ssl server socket to the 
same port.

Init can still be used for any other settings we might want to pass. 
The only other thing I can think of off the top of my head would be if 
we were using some load balancing system, where a server redirects 
clients to a less busy server or something.  But other things could come 
up that we could tuck in here.


>            
>     
> 1.  Login/Logoff
>     
>     The following request will login a user into the system
>     after the "Init" request has successfully processed.
>     
>     Client:
>          <Agenda>
>              <Login username="jackl", password="jackrabbit"/>
>          </Agenda>
>     Server:
>          <Agenda>
>              <StatusMessage success="1">jackl logged in</StatusMessage>    -- successful login
>          </Agenda>
> 
>             OR. . .
>          <Agenda>
>              <StatusMessage success="0>Invalid user: jackl</StatusMessage>
>          </Agenda>
> 
>     Client:
>          <Agenda>  
>              <Logoff/>
>          </Agenda>
>     Server:
>          <Agenda>
>              <StatusMessage success="1">jack1 logged off from ??</StatusMessage>
>          </Agenda>
> 
> 
> 2.  Email APIs
> 
>     A.  Request an email by id (each email will have a uniqueId)
>         and only return header information (format="header").
>         If you want complete email, user format="complete".  
>         This will return all information for the message (sender, cc, bcc,
>         attachment, body, etc. . )


This is a good idea.  Will provide some flexibility on the client side 
to deal with things like slow links or user preference or whatever.


> 
>         Client:
>             <Agenda>
>                <RetreiveMailMessageRequest format="header">
>                   <Uid>dkkfjslwiefoweif22320239</Uid>  -- 1 or more Uids
>                </RetrieveMailMessageRequest>
>             </Agenda>
>         Server:
>             <Agenda>
>                <MailMessageReply>
>                    <MailMessage>    -- 1 or more messages
>                    .............
>                    </MailMessage>
>                </MailMessageReply>
>             </Agenda>
> 
>     B.  Request any new (complete) messages  since July 3, 2001 @ 2:00 pm


 From the client point of view, it would be easier to deal with seconds 
from Jan 1, 1970 (epoch), as that is how Java measures time.  Other 
formats, like the one below, is fine if it's easier that way on the 
server, but epoch time saves me a line or 2 of code every time I use it.

Which also brings up the point, that I think the server should send a 
time stamp (preferably seconds since epoch) to the client when the 
client requests all messages.  What this does is gives us an easy way to 
retrieve msgs since a certain time, that won't be screwed up by 
workstations with their clocks off, or clients that switch timezones.


> 
>         Client:
>             <Agenda>
>                <RetrieveMailMessageRequest format="complete">
>                   <LastCheckTime value="200107031400"/>
>                </RetrieveMailMessageRequest>
>             </Agenda>
>         Server:
>             <Agenda>
>                 <MailMessageReply>
>                    <MailMessage>  -- 0-n mail messages
>                     ............
>                    </MailMessage>
>                    <MailMessage>
>                    .............
>                    </MailMessage>
>                 </MailMessageReply>
>             <Agenda>
> 
>         We may be able to use a timestamp such as "0"
>         to indicate that we want all messages.
> 
>                
>     C.  Send a new message
> 
>         Client:
>             <Agenda>
>                <NewMailMessageRequest>
>                    <MailMessage> --  1-n mail messages
>                    ............
>                    </MailMessage>
>                </NewMailMessageRequest>
>             </Agenda>
>         Server:
>             <Agenda>
>                 <StatusMessage success="1">Message sent successfully</StatusMessage>
>             </Agenda>
> 
>        
>     D.  Delete a message given 1 or more unique ids
>             
>         Client:
>              <Agenda>
>                  <DeleteMailMessageRequest>
>                    <Uid>kdjflslfksj</Uid> -- one or more uids
>                  </DeleteMailMessageRequest>
>              </Agenda>
>         Server:
>              <Agenda>
>                  <StatusMessage success="1">Message ??? deleted</StatusMessage>
>              </Agenda>
> 
>        
>     E.  Update a message.  This may include changing the "view" it's associated with
>         and other things like that.  The original message itself won't change, just a few attributes
>         that are associated with it for sorting, searching, folder location, etc. . .
> 
>         Client:
>             <Agenda>
>                 <UpdateMailMessageRequest>
>                    <MailMessageUpdate>   -- 1 or more mail message update
>                       <Uid>kdsjf</Uid>
>                       <Attributes>laksdjf;lsdkjf</Attributes>
>                    </MailMessageUpdate>
>                 </UpdateMailMessageRequest>
>             </Agenda>
>         Server:
>             <Agenda>
>                <StatusMessage success="1">Messages updated</StatusMessage>
>             </Agenda>
> 
> 2.  Directory APIs
> 
>     A.  Request a directory entry based on uid (summary or complete).
>         
>         The format parameter can be "summary" or "complete".  This is similar
>         to the email API where you can receive just header information
>         or the entire message, the same goes for directory entries.
>         Client:
>            <Agenda>
>                <RetrieveDirectoryRequest format="summary">
>                    <Uid>kdkdkdkd</Uid>  -- 1 or more uids
>                </RetrieveDirectoryRequest>
>            </Agenda>
>         Server:
>            <Agenda>
>                <DirectoryEntryReply>
>                    <DirectoryEntry> -- 0 or more replies
>                     ..............
>                    </DirectoryEntry>
>                </DirecotryEntryReply>
>            </Agenda>        
>         
>     B.  Request a directory entry or entries based on search parameters.
> 
>         Client:
>            <Agenda>
>                <RetrieveDirectoryRequest format="summary">
>                    <DirectorySearch>
>                       <SearchParms>  -- 1 or more search parameters
>                       </SearchParms>
>                    <DirectorySearch>
>                </RetrieveDirectoryRequest>
>            </Agenda>
>         Server:
>            <Agenda>
>                <DirectoryEntryReply>
>                    <DirectoryEntry> -- 0 or more replies
>                     ..............
>                    </DirectoryEntry>
>                </DirecotryEntryReply>
>            </Agenda>
>         
>     C.  Update a directory entry (pending appropriate permissions)
> 
>         Client:
>            <Agenda>
>               <UpdateDirectoryRequest>
>                  <DirectoryEntry>  -- 1 or more entries
>                  </DirectoryEntry>
>               </UpdateDirectoryRequest>
>            </Agenda>
>         Server:
>            <Agenda>
>                <StatusMessage success="1">Entries updated</StatusMessage>
>            </Agenda>
> 
>     D.  Delete a directory entry (pending appropriate permissions)
> 
>         Client: 
>             <Agenda>
>                 <DeleteDirectoryRequest>
>                     <Uid>kksksks</Uid> -- 1 or more uids
>                 </DeleteDirectoryRequest>
>             </Agenda>
>         Server:
>             <Agenda>
>                 <StatusMessage success="1">Entry deleted</StatusMessage>
>             </Agenda>
> 
>  
> 3.  Administration APIs
>     
>     All APIs below are performed assuming an appropriate administrator has logged in.


Up to now, I had assumed we would do a server based admin tool.  But I 
like this.  I will add an admin gui to the client side.  On the server 
we can just provide some command line tool(s) to do the same stuff.


> 
>     A.  Add a user to the system (this implies adding to the directory also)
> 
>         Client:
>             <Agenda>
>                <AdminRequest>
>                    <UserAdd>
>                        <User>  1 or more users
>                        </User>
>                    </UserAdd>
>                </AdminRequest>
>             </Agenda>
>         Server:
>             <Agenda>
>                <StatusMessage success="1">Users added</StatusMessage>
>             </Agenda>
> 
>     B.  Edit a user in the system.
> 
>         Client:
>             <Agenda>
>                <AdminRequest>
>                    <UserEdit>
>                        <User> -- 1 or more users
>                        </User>
>                    </UserEdit>
>                </AdminRequest>
>             </Agenda>
>         Server:
>             <Agenda>
>                <StatusMessage success="1">Users edited</StatusMessage>
>             </Agenda>
> 
>     C.  Delete user from the system.
> 
>         Client:
>             <Agenda>
>                <AdminRequest>
>                    <UserDelete>
>                        <Uid></Uid> -- 1 or more uids
>                    </UserDelete>
>                </AdminRequest>
>             </Agenda>
>         Server:
>             <Agenda>
>                <StatusMessage success="1">Users deleted</StatusMessage>
>             </Agenda>
> 
>     D.  Query if user is logged on.
> 
>         Client:
>             <Agenda>
>                <AdminRequest>
>                    <UserLoggedIn>
>                        <Username></Username> -- 1 or more uids
>                    </UserLoggedIn>
>                </AdminRequest>
>             </Agenda>
>         Server:
>             <Agenda>
>                <StatusMessage success="1">Users ?? logged in</StatusMessage>
>             </Agenda>
> 
>     E.  Query connection statistics for user if logged in.
> 
>         Client:
>             <Agenda>
>                <AdminRequest>
>                    <RetrieveConnectionStats>
>                        <Uid></Uid> -- 1 or more usernames
>                    </RetrieveConnectionStats>
>                </AdminRequest>
>             </Agenda>
>         Server:
>             <Agenda>
>                <ConnectionStats>
>                </ConnectionStats>
>             </Agenda>
> 
>     F.  Drop user's connection. 
> 
>         Client:
>             <Agenda>
>                <AdminRequest>
>                    <DropConnection>
>                        <ConnectionId></ConnectionId> -- 1 or connections
>                    </DropConnection>
>                </AdminRequest>
>             </Agenda>
>         Server:
>             <Agenda>
>                <StatusMessage success="1">Connections dropped</StatusMessage>
>             </Agenda>
> 
>     G.  Set system parameters not available in config files?
> 
>         Client:
>             <Agenda>
>                <AdminRequest>
>                    <SetSystemParameter>
>                        <Parameter></Parameter> -- 1 or more params
>                    </SetSystemParameter>
>                </AdminRequest>
>             </Agenda>
>         Server:
>             <Agenda>
>                <StatusMessage success="1">Parameters set</StatusMessage>
>             </Agenda>
>      
>     H.  Get a system parameter
> 
>         Client:
>             <Agenda>
>                <AdminRequest>
>                    <GetSystemParameter>
>                        <ParameterName></ParameterName> -- 1 or more parameters
>                    </GetSystemParameter>
>                </AdminRequest>
>             </Agenda>
>         Server:
>             <Agenda>
>                <Parameter>  -- 1 or more parameters
>                </Parameter>
>             </Agenda>
>    
>     I.  Tell system to re-read config files?
> 
>         Client:
>             <Agenda>
>                <AdminRequest>
>                    <RereadConfig/>
>                </AdminRequest>
>             </Agenda>
>         Server:
>             <Agenda>
>                <StatusMessage success="1">Configuration reread</StatusMessage>
>             </Agenda>
> 
>     J.  Tell system to clean cached information?
> 
>         Client:
>             <Agenda>
>                <AdminRequest>
>                    <PurgeCache/>
>                </AdminRequest>
>             </Agenda>
>         Server:
>             <Agenda>
>                <StatusMessage success="1">Cache purged</StatusMessage>
>             </Agenda>    
>     
>                   
> 

Re: [Agendaware-dev-server] XML APIs

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

Sorry, got trigger happy and for got to attach it.
--- Shane Turner <tur...@ya...> wrote:
> Hey everyone, here's a rough outline of some
> possible
> XML API's.  These are samples for directory,email
> and
> admin access.  I'm sure there's a lot more to list,
> so
> send me any additions/suggestions and we'll try to
> add/change them and get a working set to design
> against.
> 
> __________________________________________________
> 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

[Agendaware-dev-server] XML APIs

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

Hey everyone, here's a rough outline of some possible
XML API's.  These are samples for directory,email and
admin access.  I'm sure there's a lot more to list, so
send me any additions/suggestions and we'll try to
add/change them and get a working set to design against.

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

Re: [Agendaware-dev-server] Re: Doc

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

Yea, I'd like to have a look at the code too before we
submit it to the source tree to see if we're all on
the same page.  I'd also like it (if everyone agrees)
to have some sort of designs put together first to
show exactly what we intend to do before jumping into
coding too much plus give each other a chance to make
suggestions or maybe catch holes in the designs.  I 
submitted an archictecture layout if everyone would
take a look at it and see if it makes sense of if you
have suggestions or changes you think we should make.
Proper design is going to be crucial upfront to make
this project work.

Shane
--- zack <za...@th...> wrote:
> Hey Agyani.
> 
> Thanks for the email.  Comments inline.
> 
> zl
> 
> 
> Agyani wrote:
> 
> > Hi,
> > 
> >  
> > 
> > Tests are under way with the server. It has
> started to accept connection 
> > on port 7007 and is presently printing every input
> from the client on 
> > the stdout. I am working to make the ssl stuff
> running.
> > 
> >  
> 
> 
> 
> Shoot me the code for that when you can.  If all you
> have so far is 
> non-ssl, I'll start with that.
> 
> 
> > 
> > Gone through the doc, but I have not gone through
> the rfc mentioned 
> > (will try to go through). Your comments were
> appropriate for the 
> > iCalendar interface as nothing can be said without
> understanding the 
> > whole protocol.
> > 
> >  
> > 
> > I agree with Shane, we do require loadbalancing
> functionality, but we 
> > can have a load balancer built as a standalone
> application that can 
> > provide loadbalancing for the servers and not to
> integrate this feature 
> > in the server itself. This proposed loadbalancer
> can  have a config file 
> > which stores the information for available servers
> and then 
> > distributes incoming connection to them. If we are
> able to make the 
> > loadbalancer totally abstract form the underling
> server then this can be 
> > used with any other server
> 
> 
> An easy way to do this would be when logging into a
> server (you could 
> have primmary and secondary configged on the client)
> the server then 
> assigns you a server to use throughout the session. 
> This option still 
> leaves the database server as a single point of
> failure though, and you 
> couldn't really run a db on each server as you would
> still have to have 
> a single database.  So, the database would have to
> be clustered (beowolf 
>   maybe?).  If you have to set up a clustered
> database, it might be 
> worthwhile looking into what it would take to make
> the agenda server 
> cluster aware.  So, I guess we need to look at what
> is possible, and 
> what level of redundancy/load balancing it really
> gives us.
> 
> 
> > 
> >  
> > 
> > For connection distribution between servers for
> different functionality 
> > we can bind the loadbalancer's socket to all the
> addresses of the 
> > host(this may not be a good idea) and for each
> incoming connection the 
> > loadbalancer checks the address and distributes
> accordingly.
> > 
> > The proposed server is going to have a config file
> having various config 
> > information i.e port,ip, log etc. so to implement
> the above won't be a 
> > problem.
> > 
> >  
> > 
> > XML parsing is mostly done on document basis i.e
> the whole document is 
> > constructed and send for parsing as we require all
> the information in 
> > the document before we can act on it. So it would
> be better if we lean 
> > toward the document way.
> > 
> 
> 
> Sounds like DOM is the way to go.
> 
> 
> >  
> > 
> > I agree the client should have the functionality
> to do all his work 
> > offline and when he wants to update the server he
> simply connects to the 
> > server and updates/sends the information.
> > 
> >  
> > 
> > Some message archiving features could also be
> good.
> > 
> 
> 
> Good.  I think any archiving should be done on the
> server.
> 
> 
> >  
> > 
> > The proposed server will be more towards c++ then
> c, this gives us the 
> > upper hand in implementing class modularity and
> abstraction. Taking the 
> > case of db, the class that will provide database
> access will have a std 
> > set of methods for getting,setting,updating and
> retrieving information 
> > from the db. These std set of methods will be
> defined in a abstract 
> > database class having all pure virtual methods.
> Now the question of 
> > using other databases can be answered easily, to
> make the server use a 
> > new database the implementar has to extend the
> base class and provide 
> > the rest of the functionality, recompile the
> server and you have it 
> > working. I propose some thing similar to JDBC
> classes and their methods.
> > 
> >  
> > 
> > I don't have a static IP so my box can't be used
> as a server. You can 
> > have linux setup on you system and use it as the
> server and client both. 
> > I will be uploading all the information for
> compiling,configuring and 
> > running the server and the sql to setup the db
> with the release. Also 
> > thinking of the db structure and will come up with
> some tables and views 
> > asap.
> > 
> 
> 
> Very cool.
> 
> 
> >  
> > 
> > Well that's it, just got your new mail Re: LDAP
> will reply shortly.
> > 
> > You mentioned you needed help on the client, what
> kind of ?
> > 
> 
> 
> Yeah, right now, I am working on it, and one other
> is joining, Sandeep. 
>   We'll be doing the client, unless someone else
> wants to help.
> 
> 
> > Has every body joined the mailing list ?
> > 
> 
> 
> Everyone who has commited to the project is on the
> mailing lists.  There 
> are still a couple of people who have emailed me,
> but I am not sure they 
> are commited.
> 
> 
> >  
> 
=== message truncated ===


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

[Agendaware-dev-server] Re: Doc

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

Hey Agyani.

Thanks for the email.  Comments inline.

zl


Agyani wrote:

> Hi,
> 
>  
> 
> Tests are under way with the server. It has started to accept connection 
> on port 7007 and is presently printing every input from the client on 
> the stdout. I am working to make the ssl stuff running.
> 
>  



Shoot me the code for that when you can.  If all you have so far is 
non-ssl, I'll start with that.


> 
> Gone through the doc, but I have not gone through the rfc mentioned 
> (will try to go through). Your comments were appropriate for the 
> iCalendar interface as nothing can be said without understanding the 
> whole protocol.
> 
>  
> 
> I agree with Shane, we do require loadbalancing functionality, but we 
> can have a load balancer built as a standalone application that can 
> provide loadbalancing for the servers and not to integrate this feature 
> in the server itself. This proposed loadbalancer can  have a config file 
> which stores the information for available servers and then 
> distributes incoming connection to them. If we are able to make the 
> loadbalancer totally abstract form the underling server then this can be 
> used with any other server


An easy way to do this would be when logging into a server (you could 
have primmary and secondary configged on the client) the server then 
assigns you a server to use throughout the session.  This option still 
leaves the database server as a single point of failure though, and you 
couldn't really run a db on each server as you would still have to have 
a single database.  So, the database would have to be clustered (beowolf 
  maybe?).  If you have to set up a clustered database, it might be 
worthwhile looking into what it would take to make the agenda server 
cluster aware.  So, I guess we need to look at what is possible, and 
what level of redundancy/load balancing it really gives us.


> 
>  
> 
> For connection distribution between servers for different functionality 
> we can bind the loadbalancer's socket to all the addresses of the 
> host(this may not be a good idea) and for each incoming connection the 
> loadbalancer checks the address and distributes accordingly.
> 
> The proposed server is going to have a config file having various config 
> information i.e port,ip, log etc. so to implement the above won't be a 
> problem.
> 
>  
> 
> XML parsing is mostly done on document basis i.e the whole document is 
> constructed and send for parsing as we require all the information in 
> the document before we can act on it. So it would be better if we lean 
> toward the document way.
> 


Sounds like DOM is the way to go.


>  
> 
> I agree the client should have the functionality to do all his work 
> offline and when he wants to update the server he simply connects to the 
> server and updates/sends the information.
> 
>  
> 
> Some message archiving features could also be good.
> 


Good.  I think any archiving should be done on the server.


>  
> 
> The proposed server will be more towards c++ then c, this gives us the 
> upper hand in implementing class modularity and abstraction. Taking the 
> case of db, the class that will provide database access will have a std 
> set of methods for getting,setting,updating and retrieving information 
> from the db. These std set of methods will be defined in a abstract 
> database class having all pure virtual methods. Now the question of 
> using other databases can be answered easily, to make the server use a 
> new database the implementar has to extend the base class and provide 
> the rest of the functionality, recompile the server and you have it 
> working. I propose some thing similar to JDBC classes and their methods.
> 
>  
> 
> I don't have a static IP so my box can't be used as a server. You can 
> have linux setup on you system and use it as the server and client both. 
> I will be uploading all the information for compiling,configuring and 
> running the server and the sql to setup the db with the release. Also 
> thinking of the db structure and will come up with some tables and views 
> asap.
> 


Very cool.


>  
> 
> Well that's it, just got your new mail Re: LDAP will reply shortly.
> 
> You mentioned you needed help on the client, what kind of ?
> 


Yeah, right now, I am working on it, and one other is joining, Sandeep. 
  We'll be doing the client, unless someone else wants to help.


> Has every body joined the mailing list ?
> 


Everyone who has commited to the project is on the mailing lists.  There 
are still a couple of people who have emailed me, but I am not sure they 
are commited.


>  
> 
> rahul
> 

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

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

[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

[Agendaware-dev-server] XML Defs

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

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] LDAP thoughts

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

I was thinking about how to implement dir services with ldap, and this
is what I think so far...

It makes sense that all ldap queries go from the server to the ldap
server, and the client uses xml, per normal, to query the agenda
server.  Here is why...

1)  The client will have a private address book.  If that is in the db
(I don't think we want to put private addressbooks in ldap), then the
client will be querying the agenda server anyway for that.  So the
client just knows one way to query (XML).  

2)  It allows more for more secure ldap, as their is one account, one
host to deal with.  And if it is a remote ldap server (let's say
maintained by a different division, with a different agenda server) it
makes connectivity easier as far as going through firewalls, NATing
etc.  Not to mention account mgmt issues on ldap server.

3)  There is no reason to have a granularity per workstation for ldap
config.  And if different users have different ldap config for some
reason, addressing will be all screwed up.  One of the specs I imagined
for this is to support roaming users.  Having a centralized server (or
farm) will make this easier.

4)  Changing ldap servers will only require a change in one place.

5)  If/When scaling to multiple agenda "domains" (group of users managed
by  one or more servers), it will make server to server querying
possible (if server to server querying is what we want to do)

There are also a couple of minuses like ...

1)  More load on the server

2)  Less flexibility or granularity on a per user or workstation basis

But I think the pros outweigh the cons, specifically 1) can be overcome
with other good design, and 2) I don't think is going to be a n
advantage, just add potential pitfalls.

Anyone else have any thoughts on this?


Zack

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