agendaware-dev-db — Dev list for DB development

Re: [Agendaware-dev-db] Design

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

I have a lot of the ideas set up already that you are
speaking of.  The current version of code I have setup
also performs connection caching so the overhead of
establishing connections to the database are not a 
factor once connected.  Also, the version I have
dynamically loads the appropriate shared library that
contains the database implementation layer.  This can
all be configured through the configuration file and
no recompilation is necessary.  All one has to do is
go write the specific implementation (by implementing
the virtual classes) and then compile a shared
library.  Next, edit the configuration file and bounce
the server.  I'll post these soon, so you can start
looking at them.  The abstract classes I have setup
mirror the Java DB classes so it should be pretty
intuitive how they work.  I'm currently working on the
connection handling portion of the server.  Let me
know what you think.
--- Agyani <ag...@my...> wrote:
> Proposed Database Design:
> 
> An abstract class containig only pure virtual
> methods is used as the base class for all methods
> relating to db. The db access class extends this
> base class and provides all the necessary
> implementation. Data is shared between the server
> and the db class by way of structures(struct user
> etc), these structures have been defined in a
> different header vardef.h (VARiousDEFinitions). The
> server will work only with the methods provided by
> the Abstract base class, it creats an object
> Database db = Postgres(info) (where info is a
> structure holding data to estabils a connection to
> the db) and now works with the interface methods.
> For other db's you only extend the base class and
> replace relevalt include file and Database db =
> Oracle(info) and recompile.This is what presently is
> on and has been to some extent coded(skeleton
> ready).
> 
> 
> Ideas/Comments Required:
> 
> Thinking on the lines of Java refelection api, if we
> could come up with some way of dynamicaly
> loading/initilazing the Database object in the
> server with the relevant db class by just changing
> the name of the db in server.conf ?
> 
> Thought:
> We could have the class name and file name just the
> same and lookup for the relevant class pointed by
> the name stored in the server.conf, then create an
> object and pass it over to the server. This all
> should be done by a different class in between the
> server and the db class something like
> dbclassloader.
> 
> rahul
> 


__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

[Agendaware-dev-db] Design

[Agyani <ag...@my...>]

Proposed Database Design:

An abstract class containig only pure virtual methods is used as the =
base class for all methods relating to db. The db access class extends =
this base class and provides all the necessary implementation. Data is =
shared between the server and the db class by way of structures(struct =
user etc), these structures have been defined in a different header =
vardef.h (VARiousDEFinitions). The server will work only with the =
methods provided by the Abstract base class, it creats an object =
Database db =3D Postgres(info) (where info is a structure holding data =
to estabils a connection to the db) and now works with the interface =
methods. For other db's you only extend the base class and replace =
relevalt include file and Database db =3D Oracle(info) and =
recompile.This is what presently is on and has been to some extent =
coded(skeleton ready).


Ideas/Comments Required:

Thinking on the lines of Java refelection api, if we could come up with =
some way of dynamicaly loading/initilazing the Database object in the =
server with the relevant db class by just changing the name of the db in =
server.conf ?

Thought:
We could have the class name and file name just the same and lookup for =
the relevant class pointed by the name stored in the server.conf, then =
create an object and pass it over to the server. This all should be done =
by a different class in between the server and the db class something =
like dbclassloader.

rahul

[Agendaware-dev-db] [Fwd: Graphics]

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

For those of you who didn't pick up on the phsycic hyperlink, here is 
the link...

www.graphictree.com/agendatest/index.html


ZL



-------- Original Message --------
Subject: Graphics
Date: Tue, 20 Nov 2001 20:03:45 -0500
From: zack <za...@th...>
Reply-To: za...@th...
To: agenda-server <age...@li...>,	Agenda-client <age...@li...>,	age...@li...

These are some sketches by a guy that wants to do our logo/icons etc.  I
should be getting another set of samples from someone else, and we can
compare.

Zack

[Agendaware-dev-db] Graphics

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

These are some sketches by a guy that wants to do our logo/icons etc.  I 
should be getting another set of samples from someone else, and we can 
compare.

Zack

Re: [Agendaware-dev-db] DB Table Definitions

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

So are you suggesting something like this

table_mail				(all messages)
	msg_id
	from
	sugject
	body
	...
	

table_mailbox 
		(all users mailbox contents)
	msg_id
	user_id
	read
	folder
	project
	...

table_contacts 
			(all personal contacts)
	user_id		- this correlates to the user whose addressbook 				this contact is in
	first_name
	last_name
	...



OK, I see that.  I don't see any loss of functionality or anything.  And 
it does make it simpler to manage.  So, I am all for it.

Another thing I noticed in my design is that there are per message 
permissions.  While this would give us a lot of flexibility, it might be 
overkill.  Maybe the rights should be on a per mailbox level.  Anyone 
(dis)agree?

Also, I thought of a couple of other things.  If we make sure we stay 
flexible, mailboxes can be not just for a user, but also for a bulleting 
board (usenet like posting) with a mailbox per topic.  If we want users 
to have filters and auto-responders (out of office for instance), it 
wouldn't be very hard to have bulleting board type mailboxes, and 
calendars for resources (i.e. meeting rooms etc).  I think in this day 
and age, those are crucial pieces of groupware.

Also, on the IM, I think the easiest and best solution is to use off the 
shelf code.  So, a jabber server would be installed somewhere (they 
could even use an external one) and we will port some existing jabber 
client to our module (I have my eye on one).  This way, we don't have to 
write any code for the server for something that is open (like 
leveraging sql or ldap).  I think the server's only responsibility 
should be to tell the client the ip address of the jabber server on login.

And my last thought of the day, I agree we should focus on email first. 
  But, calendar messages and mail messages are so similar, I think that 
we can't ignore it.  My fear is that if we totally ignore it, we will 
have to come back and change the way we deal with mail messages, to 
accomodate calendaring, instead of re-inventing the wheel, so to speek. 
  So, I guess basically, on the design side, I think we should 
accomodate the calendaring in our plans (at least at a high level), and 
when we get to the coding, it can take a back seat so we can concentrate 
on email.









Shane Turner wrote:

> I was looking at the doc and just wanted to get a few
> suggestions in before I fogot them.  The initial draft
> looks good, however the one thing I don't think we
> need to do is have an individual table per user.  I
> think adding and dropping tables should be left to the
> DBA and the application should simply update them. Not
> to mention that with a lot of users, the DB
> administration could get ugly with so many tables to
> manage. I think in the messages and calendar tables,
> we need to have a msg_id (as you've already noted) and
> also have a field indicating the user id to which the
> mesg belongs.  We would then keep indexes on mesg_id
> and owner for access purposes.  I also think at this
> moment, we shouldn't worry about the calendaring stuff
> too much.  First goal should be to get email working
> properly. The key is going to be getting each
> component working well (extremely), and then slowly
> adding the others.  I may try to add to your db design
> a little later if I find the time, I'm still working
> on some server code design at the moment.  
> 
> --- zack <za...@th...> wrote:
> 
>>OK everyone.  I put together an initial draft of
>>what I think is needed 
>>in the database.  I organized it by table and field.
>>
>>Keep in mind, I do not do much (any) database work,
>>so there might be 
>>some flaws in my thinking, this is just a starting
>>point.  I have also 
>>left some ??? in there as well.  Not complete, but I
>>ran out of brain.
>>
>>Also, it is checked in cvs under db/docs.
>>
>>Have a look.  Send me any changes/addition/deletions
>>you can think of.
>>
>>Also, does anyone want to write some sql scripts for
>>generating the 
>>tables?  There could also be a "test data" script
>>for populating some 
>>fluff data, just to make testing easier (a couple of
>>users at least, and 
>>maybe a mail message or 2).
>>
>>Zack
>>
>>
>>_______________________________________________
>>Agendaware-dev-db mailing list
>>Age...@li...
>>
>>
> https://lists.sourceforge.net/lists/listinfo/agendaware-dev-db
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Find the one for you at Yahoo! Personals
> http://personals.yahoo.com
> 
> _______________________________________________
> Agendaware-dev-db mailing list
> Age...@li...
> https://lists.sourceforge.net/lists/listinfo/agendaware-dev-db
> 
> 
> 

Re: [Agendaware-dev-db] DB Table Definitions

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

I was looking at the doc and just wanted to get a few
suggestions in before I fogot them.  The initial draft
looks good, however the one thing I don't think we
need to do is have an individual table per user.  I
think adding and dropping tables should be left to the
DBA and the application should simply update them. Not
to mention that with a lot of users, the DB
administration could get ugly with so many tables to
manage. I think in the messages and calendar tables,
we need to have a msg_id (as you've already noted) and
also have a field indicating the user id to which the
mesg belongs.  We would then keep indexes on mesg_id
and owner for access purposes.  I also think at this
moment, we shouldn't worry about the calendaring stuff
too much.  First goal should be to get email working
properly. The key is going to be getting each
component working well (extremely), and then slowly
adding the others.  I may try to add to your db design
a little later if I find the time, I'm still working
on some server code design at the moment.  

--- zack <za...@th...> wrote:
> OK everyone.  I put together an initial draft of
> what I think is needed 
> in the database.  I organized it by table and field.
> 
> Keep in mind, I do not do much (any) database work,
> so there might be 
> some flaws in my thinking, this is just a starting
> point.  I have also 
> left some ??? in there as well.  Not complete, but I
> ran out of brain.
> 
> Also, it is checked in cvs under db/docs.
> 
> Have a look.  Send me any changes/addition/deletions
> you can think of.
> 
> Also, does anyone want to write some sql scripts for
> generating the 
> tables?  There could also be a "test data" script
> for populating some 
> fluff data, just to make testing easier (a couple of
> users at least, and 
> maybe a mail message or 2).
> 
> Zack
> 
> 
> _______________________________________________
> Agendaware-dev-db mailing list
> Age...@li...
>
https://lists.sourceforge.net/lists/listinfo/agendaware-dev-db


__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com

[Agendaware-dev-db] DB Table Definitions

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

OK everyone.  I put together an initial draft of what I think is needed 
in the database.  I organized it by table and field.

Keep in mind, I do not do much (any) database work, so there might be 
some flaws in my thinking, this is just a starting point.  I have also 
left some ??? in there as well.  Not complete, but I ran out of brain.

Also, it is checked in cvs under db/docs.

Have a look.  Send me any changes/addition/deletions you can think of.

Also, does anyone want to write some sql scripts for generating the 
tables?  There could also be a "test data" script for populating some 
fluff data, just to make testing easier (a couple of users at least, and 
maybe a mail message or 2).

Zack