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