[sip-comm-dev] GSoC Progress Report : Storing chat history in a Database


#1

Hi all

As a part of my GSoC project, I have developed a new meta contact list
service implementation based on the database service developed by me
earlier and have committed the code to my branch.

To store the contact list (which naturally has a hierarchical
structure) in tables, I have used four tables to store
MetaContactGroups,MetaContacts,ProtoContactGroups and ProtoContacts
separately.To depict the relation between these (parent child
relationships b/w XML nodes), the child records maintain the UIDs of
their parent groups, protogroups or metacontacts as applicable.

Kindly give your comments and suggestions regarding the new impl.

Regards

Ajay

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hi all

The structure of the tables used in the database is as follows:

1. The MetaContactGroups are stored in a table named "METAGROUP". It
contains the following fields:

  a."NAME" -the MetaContactGroup's Name

  b."UID" - the MetaContactGroup's UID

  c. "PERSISTENT_DATA" - the MetaContactGroup's Pessistent Data

  d."GROUP_UID"- the MetaContactGroup's Parent Group UID

2 The ProtoContactGroups are stored in a table named "PROTOGROUP". It
contains the following fields:

    a."UID"- the ProtoContactGroup's UID

    b."ACCOUNT_ID" - the ProtoContactGroup's Account ID

    c. "PARENT_UID"- the ProtoContactGroup's Parent

    d. "PERSISTENT_DATA" - the ProtoContactGroup's Persistent Data

    e. "GROUP_UID" - the ProtoContactGroup's Parent Group UID

3 The MetaContacts are stored in a table named "METACONTACT". It
contains the following fields:

    a. "UID" - the MetaContacts's UID

    b. "DISPLAY_NAME" - the MetaContacts's Display Name

    c. "DETAIL" - the MetaContacts's Details

    d. "GROUP_UID" - the MetaContacts's Parent Group UID

4 The ProtoContacts are stored in a table named "CONTACT". It
contains the following fields:

   a. "CONTACT" - the ProtoContacts

   b. "ADDRESS" - the ProtoContact's Address

   c. "ACCOUNT_ID" - the ProtoContact's Account ID

   d. "PERSISTENT_DATA" - the ProtoContact's Persistent Data

   e. "METACONTACT_UID" - the ProtoContact's Parent MetaContact UID

   f. "PROTOGROUP_UID" - the ProtoContact's Parent ProtoGroup UID

   g. "GROUP_UID" - the ProtoContact's Parent Group UID

Regards

Ajay

···

On Sat, Jul 25, 2009 at 3:08 PM, AJAY CHHATWAL<ajay.chhatwal.cse07@itbhu.ac.in> wrote:

Hi all

As a part of my GSoC project, I have developed a new meta contact list
service implementation based on the database service developed by me
earlier and have committed the code to my branch.

To store the contact list (which naturally has a hierarchical
structure) in tables, I have used four tables to store
MetaContactGroups,MetaContacts,ProtoContactGroups and ProtoContacts
separately.To depict the relation between these (parent child
relationships b/w XML nodes), the child records maintain the UIDs of
their parent groups, protogroups or metacontacts as applicable.

Kindly give your comments and suggestions regarding the new impl.

Regards

Ajay

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi emil

Hey Ajay,

Looks reasonable. A few comments though:

* Protocols like XMPP and MSN allow having one and the same contact in
multiple groups. We don't currently support this and always pick one
group, but we will have to fix it one day.

It may therefore be worth taking the case into account in the table
design. Possibly by moving the relation to a separate table.

I believe that current design of the tables will support the behavior
mentioned above by making simple changes like parsing the Parent Group
as a a list of strings separated by a special unicode character.This
would be more efficient than moving the relation into a seperate
table.

* I don't quite understand the need of storing the parent meta group in
the Contacts table. Wouldn't it be enough to only have the parent proto
group?

Yes, it would be enough to only have the parent proto group.I have
included the parent meta group in order to make group operations such
as deletion etc. easier .

* In the METAGROUP group table, could you please rename the GROUP_UID
column to PARENT_METAGROUP_UID?

* In the PROTOGROUP table, could you please rename the GROUP_UID and the
PARENT_UID to PARENT_PRTOGROUP_UID and PARENT_METAGROUP_UID (Not
necessarily in that order cause I couldn't really figure what they
correspond to based on their descriptions).

I would rename them as desired by you.

* There could be multiple DETAIL's per meta contact so it might be worth
moving those to a separate table as well.

This is not required as the details are stored as a hash table in the
form of a Java object in the database table.

That's all I can think of right now. Let me know if you have any questiosn!

Cheers
Emil

Hope this answers your questions.Let me know if have any more comments
or questions

Regards

Ajay

···

On 7/25/09, Emil Ivov <emcho@sip-communicator.org> wrote:

AJAY CHHATWAL wrote:

Hi all

The structure of the tables used in the database is as follows:

1. The MetaContactGroups are stored in a table named "METAGROUP". It
contains the following fields:

  a."NAME" -the MetaContactGroup's Name

  b."UID" - the MetaContactGroup's UID

  c. "PERSISTENT_DATA" - the MetaContactGroup's Pessistent Data

  d."GROUP_UID"- the MetaContactGroup's Parent Group UID

2 The ProtoContactGroups are stored in a table named "PROTOGROUP". It
contains the following fields:

    a."UID"- the ProtoContactGroup's UID

    b."ACCOUNT_ID" - the ProtoContactGroup's Account ID

    c. "PARENT_UID"- the ProtoContactGroup's Parent

    d. "PERSISTENT_DATA" - the ProtoContactGroup's Persistent Data

    e. "GROUP_UID" - the ProtoContactGroup's Parent Group UID

3 The MetaContacts are stored in a table named "METACONTACT". It
contains the following fields:

    a. "UID" - the MetaContacts's UID

    b. "DISPLAY_NAME" - the MetaContacts's Display Name

    c. "DETAIL" - the MetaContacts's Details

    d. "GROUP_UID" - the MetaContacts's Parent Group UID

4 The ProtoContacts are stored in a table named "CONTACT". It
contains the following fields:

   a. "CONTACT" - the ProtoContacts

   b. "ADDRESS" - the ProtoContact's Address

   c. "ACCOUNT_ID" - the ProtoContact's Account ID

   d. "PERSISTENT_DATA" - the ProtoContact's Persistent Data

   e. "METACONTACT_UID" - the ProtoContact's Parent MetaContact UID

   f. "PROTOGROUP_UID" - the ProtoContact's Parent ProtoGroup UID

   g. "GROUP_UID" - the ProtoContact's Parent Group UID

Regards

Ajay

On Sat, Jul 25, 2009 at 3:08 PM, AJAY >> CHHATWAL<ajay.chhatwal.cse07@itbhu.ac.in> wrote:

Hi all

As a part of my GSoC project, I have developed a new meta contact list
service implementation based on the database service developed by me
earlier and have committed the code to my branch.

To store the contact list (which naturally has a hierarchical
structure) in tables, I have used four tables to store
MetaContactGroups,MetaContacts,ProtoContactGroups and ProtoContacts
separately.To depict the relation between these (parent child
relationships b/w XML nodes), the child records maintain the UIDs of
their parent groups, protogroups or metacontacts as applicable.

Kindly give your comments and suggestions regarding the new impl.

Regards

Ajay

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hey Ajay,

Looks reasonable. A few comments though:

* Protocols like XMPP and MSN allow having one and the same contact in
multiple groups. We don't currently support this and always pick one
group, but we will have to fix it one day.

It may therefore be worth taking the case into account in the table
design. Possibly by moving the relation to a separate table.

* I don't quite understand the need of storing the parent meta group in
the Contacts table. Wouldn't it be enough to only have the parent proto
group?

* In the METAGROUP group table, could you please rename the GROUP_UID
column to PARENT_METAGROUP_UID?

* In the PROTOGROUP table, could you please rename the GROUP_UID and the
PARENT_UID to PARENT_PRTOGROUP_UID and PARENT_METAGROUP_UID (Not
necessarily in that order cause I couldn't really figure what they
correspond to based on their descriptions).

* There could be multiple DETAIL's per meta contact so it might be worth
moving those to a separate table as well.

That's all I can think of right now. Let me know if you have any questiosn!

Cheers
Emil

AJAY CHHATWAL wrote:

···

Hi all

The structure of the tables used in the database is as follows:

1. The MetaContactGroups are stored in a table named "METAGROUP". It
contains the following fields:

  a."NAME" -the MetaContactGroup's Name

  b."UID" - the MetaContactGroup's UID

  c. "PERSISTENT_DATA" - the MetaContactGroup's Pessistent Data

  d."GROUP_UID"- the MetaContactGroup's Parent Group UID

2 The ProtoContactGroups are stored in a table named "PROTOGROUP". It
contains the following fields:

    a."UID"- the ProtoContactGroup's UID

    b."ACCOUNT_ID" - the ProtoContactGroup's Account ID

    c. "PARENT_UID"- the ProtoContactGroup's Parent

    d. "PERSISTENT_DATA" - the ProtoContactGroup's Persistent Data

    e. "GROUP_UID" - the ProtoContactGroup's Parent Group UID

3 The MetaContacts are stored in a table named "METACONTACT". It
contains the following fields:

    a. "UID" - the MetaContacts's UID

    b. "DISPLAY_NAME" - the MetaContacts's Display Name

    c. "DETAIL" - the MetaContacts's Details

    d. "GROUP_UID" - the MetaContacts's Parent Group UID

4 The ProtoContacts are stored in a table named "CONTACT". It
contains the following fields:

   a. "CONTACT" - the ProtoContacts

   b. "ADDRESS" - the ProtoContact's Address

   c. "ACCOUNT_ID" - the ProtoContact's Account ID

   d. "PERSISTENT_DATA" - the ProtoContact's Persistent Data

   e. "METACONTACT_UID" - the ProtoContact's Parent MetaContact UID

   f. "PROTOGROUP_UID" - the ProtoContact's Parent ProtoGroup UID

   g. "GROUP_UID" - the ProtoContact's Parent Group UID

Regards

Ajay

On Sat, Jul 25, 2009 at 3:08 PM, AJAY > CHHATWAL<ajay.chhatwal.cse07@itbhu.ac.in> wrote:

Hi all

As a part of my GSoC project, I have developed a new meta contact list
service implementation based on the database service developed by me
earlier and have committed the code to my branch.

To store the contact list (which naturally has a hierarchical
structure) in tables, I have used four tables to store
MetaContactGroups,MetaContacts,ProtoContactGroups and ProtoContacts
separately.To depict the relation between these (parent child
relationships b/w XML nodes), the child records maintain the UIDs of
their parent groups, protogroups or metacontacts as applicable.

Kindly give your comments and suggestions regarding the new impl.

Regards

Ajay

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi Emil,

Could you please elaborate a bit on the structure of an extra relation table.

Regards

Ajay

···

On Sun, Jul 26, 2009 at 12:39 AM, Emil Ivov<emcho@sip-communicator.org> wrote:

Hey Ajay,

Hi emil

On 7/25/09, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Ajay,

Looks reasonable. A few comments though:

* Protocols like XMPP and MSN allow having one and the same contact in
multiple groups. We don't currently support this and always pick one
group, but we will have to fix it one day.

It may therefore be worth taking the case into account in the table
design. Possibly by moving the relation to a separate table.

I believe that current design of the tables will support the behavior
mentioned above by making simple changes like parsing the Parent Group
as a a list of strings separated by a special unicode character.This
would be more efficient than moving the relation into a seperate table.

This would work indeed, however, we are moving away from xml so that we
don't have to do any parsing in such sitiations, so I'd prefer we went for
an extra relation table. This should also improve contact loopup in cases of
multiple parents and would spare us the need to implement
shieldingmechanisms.

* I don't quite understand the need of storing the parent meta group in
the Contacts table. Wouldn't it be enough to only have the parent proto
group?

Yes, it would be enough to only have the parent proto group.I have
included the parent meta group in order to make group operations such as
deletion etc. easier .

I am not sure I understand how this would improve group deletion. If you are
to remove a meta group you'd have to lookup and remove all its protogroups
anyway.

* In the METAGROUP group table, could you please rename the GROUP_UID
column to PARENT_METAGROUP_UID?

* In the PROTOGROUP table, could you please rename the GROUP_UID and the
PARENT_UID to PARENT_PRTOGROUP_UID and PARENT_METAGROUP_UID (Not
necessarily in that order cause I couldn't really figure what they
correspond to based on their descriptions).

I would rename them as desired by you.

* There could be multiple DETAIL's per meta contact so it might be worth
moving those to a separate table as well.

This is not required as the details are stored as a hash table in the form
of a Java object in the database table.

Is there any specific reason for this? Why would we want to absolutely
deserialize egery time we need a single detail?

Once again, replacing xml storage with a db is a serious effort anyway so
lets try to benefit from it as best as we can.

Emil

--sent from my mobile

That's all I can think of right now. Let me know if you have any
questiosn!

Cheers
Emil

Hope this answers your questions.Let me know if have any more comments
or questions

Regards

Ajay

AJAY CHHATWAL wrote:

Hi all

The structure of the tables used in the database is as follows:

1. The MetaContactGroups are stored in a table named "METAGROUP". It
contains the following fields:

a."NAME" -the MetaContactGroup's Name

b."UID" - the MetaContactGroup's UID

c. "PERSISTENT_DATA" - the MetaContactGroup's Pessistent Data

d."GROUP_UID"- the MetaContactGroup's Parent Group UID

2 The ProtoContactGroups are stored in a table named "PROTOGROUP". It
contains the following fields:

a."UID"- the ProtoContactGroup's UID

b."ACCOUNT_ID" - the ProtoContactGroup's Account ID

c. "PARENT_UID"- the ProtoContactGroup's Parent

d. "PERSISTENT_DATA" - the ProtoContactGroup's Persistent Data

e. "GROUP_UID" - the ProtoContactGroup's Parent Group UID

3 The MetaContacts are stored in a table named "METACONTACT". It
contains the following fields:

a. "UID" - the MetaContacts's UID

b. "DISPLAY_NAME" - the MetaContacts's Display Name

c. "DETAIL" - the MetaContacts's Details

d. "GROUP_UID" - the MetaContacts's Parent Group UID

4 The ProtoContacts are stored in a table named "CONTACT". It
contains the following fields:

a. "CONTACT" - the ProtoContacts

b. "ADDRESS" - the ProtoContact's Address

c. "ACCOUNT_ID" - the ProtoContact's Account ID

d. "PERSISTENT_DATA" - the ProtoContact's Persistent Data

e. "METACONTACT_UID" - the ProtoContact's Parent MetaContact UID

f. "PROTOGROUP_UID" - the ProtoContact's Parent ProtoGroup UID

g. "GROUP_UID" - the ProtoContact's Parent Group UID

Regards

Ajay

On Sat, Jul 25, 2009 at 3:08 PM, AJAY >>>> CHHATWAL<ajay.chhatwal.cse07@itbhu.ac.in> wrote:

Hi all

As a part of my GSoC project, I have developed a new meta contact list
service implementation based on the database service developed by me
earlier and have committed the code to my branch.

To store the contact list (which naturally has a hierarchical
structure) in tables, I have used four tables to store
MetaContactGroups,MetaContacts,ProtoContactGroups and ProtoContacts
separately.To depict the relation between these (parent child
relationships b/w XML nodes), the child records maintain the UIDs of
their parent groups, protogroups or metacontacts as applicable.

Kindly give your comments and suggestions regarding the new impl.

Regards

Ajay

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hi emil

I understand your point now.Will try to modify my impl.

Regards

Ajay

···

On Sun, Jul 26, 2009 at 5:09 PM, Emil Ivov<emcho@sip-communicator.org> wrote:

Oh, I was thinking of sth quite simple really. A 2-column table, mapping
contacts to parent groups, should do the job.

Wdyt?
Emil

--sent from my mobile

On 26 juil. 2009, at 13:23, AJAY CHHATWAL <ajay.chhatwal.cse07@itbhu.ac.in> > wrote:

Hi Emil,

Could you please elaborate a bit on the structure of an extra relation
table.

Regards

Ajay

On Sun, Jul 26, 2009 at 12:39 AM, Emil Ivov<emcho@sip-communicator.org> >> wrote:

Hey Ajay,

Hi emil

On 7/25/09, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Ajay,

Looks reasonable. A few comments though:

* Protocols like XMPP and MSN allow having one and the same contact in
multiple groups. We don't currently support this and always pick one
group, but we will have to fix it one day.

It may therefore be worth taking the case into account in the table
design. Possibly by moving the relation to a separate table.

I believe that current design of the tables will support the behavior
mentioned above by making simple changes like parsing the Parent Group
as a a list of strings separated by a special unicode character.This
would be more efficient than moving the relation into a seperate table.

This would work indeed, however, we are moving away from xml so that we
don't have to do any parsing in such sitiations, so I'd prefer we went
for
an extra relation table. This should also improve contact loopup in cases
of
multiple parents and would spare us the need to implement
shieldingmechanisms.

* I don't quite understand the need of storing the parent meta group in
the Contacts table. Wouldn't it be enough to only have the parent proto
group?

Yes, it would be enough to only have the parent proto group.I have
included the parent meta group in order to make group operations such as
deletion etc. easier .

I am not sure I understand how this would improve group deletion. If you
are
to remove a meta group you'd have to lookup and remove all its
protogroups
anyway.

* In the METAGROUP group table, could you please rename the GROUP_UID
column to PARENT_METAGROUP_UID?

* In the PROTOGROUP table, could you please rename the GROUP_UID and
the
PARENT_UID to PARENT_PRTOGROUP_UID and PARENT_METAGROUP_UID (Not
necessarily in that order cause I couldn't really figure what they
correspond to based on their descriptions).

I would rename them as desired by you.

* There could be multiple DETAIL's per meta contact so it might be
worth
moving those to a separate table as well.

This is not required as the details are stored as a hash table in the
form
of a Java object in the database table.

Is there any specific reason for this? Why would we want to absolutely
deserialize egery time we need a single detail?

Once again, replacing xml storage with a db is a serious effort anyway so
lets try to benefit from it as best as we can.

Emil

--sent from my mobile

That's all I can think of right now. Let me know if you have any
questiosn!

Cheers
Emil

Hope this answers your questions.Let me know if have any more comments
or questions

Regards

Ajay

AJAY CHHATWAL wrote:

Hi all

The structure of the tables used in the database is as follows:

1. The MetaContactGroups are stored in a table named "METAGROUP". It
contains the following fields:

a."NAME" -the MetaContactGroup's Name

b."UID" - the MetaContactGroup's UID

c. "PERSISTENT_DATA" - the MetaContactGroup's Pessistent Data

d."GROUP_UID"- the MetaContactGroup's Parent Group UID

2 The ProtoContactGroups are stored in a table named "PROTOGROUP". It
contains the following fields:

a."UID"- the ProtoContactGroup's UID

b."ACCOUNT_ID" - the ProtoContactGroup's Account ID

c. "PARENT_UID"- the ProtoContactGroup's Parent

d. "PERSISTENT_DATA" - the ProtoContactGroup's Persistent Data

e. "GROUP_UID" - the ProtoContactGroup's Parent Group UID

3 The MetaContacts are stored in a table named "METACONTACT". It
contains the following fields:

a. "UID" - the MetaContacts's UID

b. "DISPLAY_NAME" - the MetaContacts's Display Name

c. "DETAIL" - the MetaContacts's Details

d. "GROUP_UID" - the MetaContacts's Parent Group UID

4 The ProtoContacts are stored in a table named "CONTACT". It
contains the following fields:

a. "CONTACT" - the ProtoContacts

b. "ADDRESS" - the ProtoContact's Address

c. "ACCOUNT_ID" - the ProtoContact's Account ID

d. "PERSISTENT_DATA" - the ProtoContact's Persistent Data

e. "METACONTACT_UID" - the ProtoContact's Parent MetaContact UID

f. "PROTOGROUP_UID" - the ProtoContact's Parent ProtoGroup UID

g. "GROUP_UID" - the ProtoContact's Parent Group UID

Regards

Ajay

On Sat, Jul 25, 2009 at 3:08 PM, AJAY >>>>>> CHHATWAL<ajay.chhatwal.cse07@itbhu.ac.in> wrote:

Hi all

As a part of my GSoC project, I have developed a new meta contact
list
service implementation based on the database service developed by me
earlier and have committed the code to my branch.

To store the contact list (which naturally has a hierarchical
structure) in tables, I have used four tables to store
MetaContactGroups,MetaContacts,ProtoContactGroups and ProtoContacts
separately.To depict the relation between these (parent child
relationships b/w XML nodes), the child records maintain the UIDs of
their parent groups, protogroups or metacontacts as applicable.

Kindly give your comments and suggestions regarding the new impl.

Regards

Ajay

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi emil

I have modified the contact list implementation to allow the
MetaContacts to have multiple parent MetaContactGroups by using a
separate relation table and have renamed the Constant desired by you
and have committed the code to my branch

Regards

Ajay

···

On Sun, Jul 26, 2009 at 5:17 PM, AJAY CHHATWAL<ajay.chhatwal.cse07@itbhu.ac.in> wrote:

Hi emil

I understand your point now.Will try to modify my impl.

Regards

Ajay

On Sun, Jul 26, 2009 at 5:09 PM, Emil Ivov<emcho@sip-communicator.org> wrote:

Oh, I was thinking of sth quite simple really. A 2-column table, mapping
contacts to parent groups, should do the job.

Wdyt?
Emil

--sent from my mobile

On 26 juil. 2009, at 13:23, AJAY CHHATWAL <ajay.chhatwal.cse07@itbhu.ac.in> >> wrote:

Hi Emil,

Could you please elaborate a bit on the structure of an extra relation
table.

Regards

Ajay

On Sun, Jul 26, 2009 at 12:39 AM, Emil Ivov<emcho@sip-communicator.org> >>> wrote:

Hey Ajay,

Hi emil

On 7/25/09, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Ajay,

Looks reasonable. A few comments though:

* Protocols like XMPP and MSN allow having one and the same contact in
multiple groups. We don't currently support this and always pick one
group, but we will have to fix it one day.

It may therefore be worth taking the case into account in the table
design. Possibly by moving the relation to a separate table.

I believe that current design of the tables will support the behavior
mentioned above by making simple changes like parsing the Parent Group
as a a list of strings separated by a special unicode character.This
would be more efficient than moving the relation into a seperate table.

This would work indeed, however, we are moving away from xml so that we
don't have to do any parsing in such sitiations, so I'd prefer we went
for
an extra relation table. This should also improve contact loopup in cases
of
multiple parents and would spare us the need to implement
shieldingmechanisms.

* I don't quite understand the need of storing the parent meta group in
the Contacts table. Wouldn't it be enough to only have the parent proto
group?

Yes, it would be enough to only have the parent proto group.I have
included the parent meta group in order to make group operations such as
deletion etc. easier .

I am not sure I understand how this would improve group deletion. If you
are
to remove a meta group you'd have to lookup and remove all its
protogroups
anyway.

* In the METAGROUP group table, could you please rename the GROUP_UID
column to PARENT_METAGROUP_UID?

* In the PROTOGROUP table, could you please rename the GROUP_UID and
the
PARENT_UID to PARENT_PRTOGROUP_UID and PARENT_METAGROUP_UID (Not
necessarily in that order cause I couldn't really figure what they
correspond to based on their descriptions).

I would rename them as desired by you.

* There could be multiple DETAIL's per meta contact so it might be
worth
moving those to a separate table as well.

This is not required as the details are stored as a hash table in the
form
of a Java object in the database table.

Is there any specific reason for this? Why would we want to absolutely
deserialize egery time we need a single detail?

Once again, replacing xml storage with a db is a serious effort anyway so
lets try to benefit from it as best as we can.

Emil

--sent from my mobile

That's all I can think of right now. Let me know if you have any
questiosn!

Cheers
Emil

Hope this answers your questions.Let me know if have any more comments
or questions

Regards

Ajay

AJAY CHHATWAL wrote:

Hi all

The structure of the tables used in the database is as follows:

1. The MetaContactGroups are stored in a table named "METAGROUP". It
contains the following fields:

a."NAME" -the MetaContactGroup's Name

b."UID" - the MetaContactGroup's UID

c. "PERSISTENT_DATA" - the MetaContactGroup's Pessistent Data

d."GROUP_UID"- the MetaContactGroup's Parent Group UID

2 The ProtoContactGroups are stored in a table named "PROTOGROUP". It
contains the following fields:

a."UID"- the ProtoContactGroup's UID

b."ACCOUNT_ID" - the ProtoContactGroup's Account ID

c. "PARENT_UID"- the ProtoContactGroup's Parent

d. "PERSISTENT_DATA" - the ProtoContactGroup's Persistent Data

e. "GROUP_UID" - the ProtoContactGroup's Parent Group UID

3 The MetaContacts are stored in a table named "METACONTACT". It
contains the following fields:

a. "UID" - the MetaContacts's UID

b. "DISPLAY_NAME" - the MetaContacts's Display Name

c. "DETAIL" - the MetaContacts's Details

d. "GROUP_UID" - the MetaContacts's Parent Group UID

4 The ProtoContacts are stored in a table named "CONTACT". It
contains the following fields:

a. "CONTACT" - the ProtoContacts

b. "ADDRESS" - the ProtoContact's Address

c. "ACCOUNT_ID" - the ProtoContact's Account ID

d. "PERSISTENT_DATA" - the ProtoContact's Persistent Data

e. "METACONTACT_UID" - the ProtoContact's Parent MetaContact UID

f. "PROTOGROUP_UID" - the ProtoContact's Parent ProtoGroup UID

g. "GROUP_UID" - the ProtoContact's Parent Group UID

Regards

Ajay

On Sat, Jul 25, 2009 at 3:08 PM, AJAY >>>>>>> CHHATWAL<ajay.chhatwal.cse07@itbhu.ac.in> wrote:

Hi all

As a part of my GSoC project, I have developed a new meta contact
list
service implementation based on the database service developed by me
earlier and have committed the code to my branch.

To store the contact list (which naturally has a hierarchical
structure) in tables, I have used four tables to store
MetaContactGroups,MetaContacts,ProtoContactGroups and ProtoContacts
separately.To depict the relation between these (parent child
relationships b/w XML nodes), the child records maintain the UIDs of
their parent groups, protogroups or metacontacts as applicable.

Kindly give your comments and suggestions regarding the new impl.

Regards

Ajay

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hey ajay,

AJAY CHHATWAL wrote:

Hi emil

I have modified the contact list implementation to allow the
MetaContacts to have multiple parent MetaContactGroups by using a
separate relation table and have renamed the Constant desired by you
and have committed the code to my branch

Thanks! Maybe you'd like to post an updated design here?

To all GSoC students: Folks, it probably appears natural to you that
people here would rush to check out your branches every time you post a
change. Some may actually do that, like for example your mentors,
however if you want more people to follow your work then you should make
it easy for them. One easy way to do that is post summaries here and
tell others about what your changes are about.

Cheers
Emil

···

Regards

Ajay

On Sun, Jul 26, 2009 at 5:17 PM, AJAY > CHHATWAL<ajay.chhatwal.cse07@itbhu.ac.in> wrote:

Hi emil

I understand your point now.Will try to modify my impl.

Regards

Ajay

On Sun, Jul 26, 2009 at 5:09 PM, Emil Ivov<emcho@sip-communicator.org> wrote:

Oh, I was thinking of sth quite simple really. A 2-column table, mapping
contacts to parent groups, should do the job.

Wdyt?
Emil

--sent from my mobile

On 26 juil. 2009, at 13:23, AJAY CHHATWAL <ajay.chhatwal.cse07@itbhu.ac.in> >>> wrote:

Hi Emil,

Could you please elaborate a bit on the structure of an extra relation
table.

Regards

Ajay

On Sun, Jul 26, 2009 at 12:39 AM, Emil Ivov<emcho@sip-communicator.org> >>>> wrote:

Hey Ajay,

Hi emil

On 7/25/09, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Ajay,

Looks reasonable. A few comments though:

* Protocols like XMPP and MSN allow having one and the same contact in
multiple groups. We don't currently support this and always pick one
group, but we will have to fix it one day.

It may therefore be worth taking the case into account in the table
design. Possibly by moving the relation to a separate table.

I believe that current design of the tables will support the behavior
mentioned above by making simple changes like parsing the Parent Group
as a a list of strings separated by a special unicode character.This
would be more efficient than moving the relation into a seperate table.

This would work indeed, however, we are moving away from xml so that we
don't have to do any parsing in such sitiations, so I'd prefer we went
for
an extra relation table. This should also improve contact loopup in cases
of
multiple parents and would spare us the need to implement
shieldingmechanisms.

* I don't quite understand the need of storing the parent meta group in
the Contacts table. Wouldn't it be enough to only have the parent proto
group?

Yes, it would be enough to only have the parent proto group.I have
included the parent meta group in order to make group operations such as
deletion etc. easier .

I am not sure I understand how this would improve group deletion. If you
are
to remove a meta group you'd have to lookup and remove all its
protogroups
anyway.

* In the METAGROUP group table, could you please rename the GROUP_UID
column to PARENT_METAGROUP_UID?

* In the PROTOGROUP table, could you please rename the GROUP_UID and
the
PARENT_UID to PARENT_PRTOGROUP_UID and PARENT_METAGROUP_UID (Not
necessarily in that order cause I couldn't really figure what they
correspond to based on their descriptions).

I would rename them as desired by you.

* There could be multiple DETAIL's per meta contact so it might be
worth
moving those to a separate table as well.

This is not required as the details are stored as a hash table in the
form
of a Java object in the database table.

Is there any specific reason for this? Why would we want to absolutely
deserialize egery time we need a single detail?

Once again, replacing xml storage with a db is a serious effort anyway so
lets try to benefit from it as best as we can.

Emil

--sent from my mobile

That's all I can think of right now. Let me know if you have any
questiosn!

Cheers
Emil

Hope this answers your questions.Let me know if have any more comments
or questions

Regards

Ajay

AJAY CHHATWAL wrote:

Hi all

The structure of the tables used in the database is as follows:

1. The MetaContactGroups are stored in a table named "METAGROUP". It
contains the following fields:

a."NAME" -the MetaContactGroup's Name

b."UID" - the MetaContactGroup's UID

c. "PERSISTENT_DATA" - the MetaContactGroup's Pessistent Data

d."GROUP_UID"- the MetaContactGroup's Parent Group UID

2 The ProtoContactGroups are stored in a table named "PROTOGROUP". It
contains the following fields:

a."UID"- the ProtoContactGroup's UID

b."ACCOUNT_ID" - the ProtoContactGroup's Account ID

c. "PARENT_UID"- the ProtoContactGroup's Parent

d. "PERSISTENT_DATA" - the ProtoContactGroup's Persistent Data

e. "GROUP_UID" - the ProtoContactGroup's Parent Group UID

3 The MetaContacts are stored in a table named "METACONTACT". It
contains the following fields:

a. "UID" - the MetaContacts's UID

b. "DISPLAY_NAME" - the MetaContacts's Display Name

c. "DETAIL" - the MetaContacts's Details

d. "GROUP_UID" - the MetaContacts's Parent Group UID

4 The ProtoContacts are stored in a table named "CONTACT". It
contains the following fields:

a. "CONTACT" - the ProtoContacts

b. "ADDRESS" - the ProtoContact's Address

c. "ACCOUNT_ID" - the ProtoContact's Account ID

d. "PERSISTENT_DATA" - the ProtoContact's Persistent Data

e. "METACONTACT_UID" - the ProtoContact's Parent MetaContact UID

f. "PROTOGROUP_UID" - the ProtoContact's Parent ProtoGroup UID

g. "GROUP_UID" - the ProtoContact's Parent Group UID

Regards

Ajay

On Sat, Jul 25, 2009 at 3:08 PM, AJAY >>>>>>>> CHHATWAL<ajay.chhatwal.cse07@itbhu.ac.in> wrote:

Hi all

As a part of my GSoC project, I have developed a new meta contact
list
service implementation based on the database service developed by me
earlier and have committed the code to my branch.

To store the contact list (which naturally has a hierarchical
structure) in tables, I have used four tables to store
MetaContactGroups,MetaContacts,ProtoContactGroups and ProtoContacts
separately.To depict the relation between these (parent child
relationships b/w XML nodes), the child records maintain the UIDs of
their parent groups, protogroups or metacontacts as applicable.

Kindly give your comments and suggestions regarding the new impl.

Regards

Ajay

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

Hi all

The modified structure of the tables used to store the contact list in
the database is as follows:

1. The MetaContactGroups are stored in a table named "METAGROUP". It
contains the following fields:

a."NAME" -the MetaContactGroup's Name

b."UID" - the MetaContactGroup's UID

c. "PERSISTENT_DATA" - the MetaContactGroup's Pessistent Data

d."GROUP_UID"- the MetaContactGroup's Parent Group UID

2 The ProtoContactGroups are stored in a table named "PROTOGROUP". It
contains the following fields:

   a."UID"- the ProtoContactGroup's UID

   b."ACCOUNT_ID" - the ProtoContactGroup's Account ID

   c. "PARENT_UID"- the ProtoContactGroup's Parent

   d. "PERSISTENT_DATA" - the ProtoContactGroup's Persistent Data

   e. "GROUP_UID" - the ProtoContactGroup's Parent Group UID

3 The MetaContacts are stored in a table named "METACONTACT". It
contains the following fields:

   a. "UID" - the MetaContacts's UID

   b. "DISPLAY_NAME" - the MetaContacts's Display Name

   c. "DETAIL" - the MetaContacts's Details

4 The MetaContacts and their Parent MetaGroups are stored in a
table named "RELATION". It contains the following fields:

   a. "METACONATCT_UID" - the MetaContacts's UID

   b. "PARENT_METAGROUP_UID" - the parent MetaGroup's UID

5 The ProtoContacts are stored in a table named "CONTACT". It
contains the following fields:

  a. "CONTACT" - the ProtoContacts

  b. "ADDRESS" - the ProtoContact's Address

  c. "ACCOUNT_ID" - the ProtoContact's Account ID

  d. "PERSISTENT_DATA" - the ProtoContact's Persistent Data

  e. "METACONTACT_UID" - the ProtoContact's Parent MetaContact UID

  f. "PROTOGROUP_UID" - the ProtoContact's Parent ProtoGroup UID

  g. "GROUP_UID" - the ProtoContact's Parent Group UID

Regards

Ajay

···

On Tue, Jul 28, 2009 at 3:12 PM, Emil Ivov<emcho@sip-communicator.org> wrote:

Hey ajay,

AJAY CHHATWAL wrote:

Hi emil

I have modified the contact list implementation to allow the
MetaContacts to have multiple parent MetaContactGroups by using a
separate relation table and have renamed the Constant desired by you
and have committed the code to my branch

Thanks! Maybe you'd like to post an updated design here?

To all GSoC students: Folks, it probably appears natural to you that
people here would rush to check out your branches every time you post a
change. Some may actually do that, like for example your mentors,
however if you want more people to follow your work then you should make
it easy for them. One easy way to do that is post summaries here and
tell others about what your changes are about.

Cheers
Emil

Regards

Ajay

On Sun, Jul 26, 2009 at 5:17 PM, AJAY >> CHHATWAL<ajay.chhatwal.cse07@itbhu.ac.in> wrote:

Hi emil

I understand your point now.Will try to modify my impl.

Regards

Ajay

On Sun, Jul 26, 2009 at 5:09 PM, Emil Ivov<emcho@sip-communicator.org> wrote:

Oh, I was thinking of sth quite simple really. A 2-column table, mapping
contacts to parent groups, should do the job.

Wdyt?
Emil

--sent from my mobile

On 26 juil. 2009, at 13:23, AJAY CHHATWAL <ajay.chhatwal.cse07@itbhu.ac.in> >>>> wrote:

Hi Emil,

Could you please elaborate a bit on the structure of an extra relation
table.

Regards

Ajay

On Sun, Jul 26, 2009 at 12:39 AM, Emil Ivov<emcho@sip-communicator.org> >>>>> wrote:

Hey Ajay,

Hi emil

On 7/25/09, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Ajay,

Looks reasonable. A few comments though:

* Protocols like XMPP and MSN allow having one and the same contact in
multiple groups. We don't currently support this and always pick one
group, but we will have to fix it one day.

It may therefore be worth taking the case into account in the table
design. Possibly by moving the relation to a separate table.

I believe that current design of the tables will support the behavior
mentioned above by making simple changes like parsing the Parent Group
as a a list of strings separated by a special unicode character.This
would be more efficient than moving the relation into a seperate table.

This would work indeed, however, we are moving away from xml so that we
don't have to do any parsing in such sitiations, so I'd prefer we went
for
an extra relation table. This should also improve contact loopup in cases
of
multiple parents and would spare us the need to implement
shieldingmechanisms.

* I don't quite understand the need of storing the parent meta group in
the Contacts table. Wouldn't it be enough to only have the parent proto
group?

Yes, it would be enough to only have the parent proto group.I have
included the parent meta group in order to make group operations such as
deletion etc. easier .

I am not sure I understand how this would improve group deletion. If you
are
to remove a meta group you'd have to lookup and remove all its
protogroups
anyway.

* In the METAGROUP group table, could you please rename the GROUP_UID
column to PARENT_METAGROUP_UID?

* In the PROTOGROUP table, could you please rename the GROUP_UID and
the
PARENT_UID to PARENT_PRTOGROUP_UID and PARENT_METAGROUP_UID (Not
necessarily in that order cause I couldn't really figure what they
correspond to based on their descriptions).

I would rename them as desired by you.

* There could be multiple DETAIL's per meta contact so it might be
worth
moving those to a separate table as well.

This is not required as the details are stored as a hash table in the
form
of a Java object in the database table.

Is there any specific reason for this? Why would we want to absolutely
deserialize egery time we need a single detail?

Once again, replacing xml storage with a db is a serious effort anyway so
lets try to benefit from it as best as we can.

Emil

--sent from my mobile

That's all I can think of right now. Let me know if you have any
questiosn!

Cheers
Emil

Hope this answers your questions.Let me know if have any more comments
or questions

Regards

Ajay

AJAY CHHATWAL wrote:

Hi all

The structure of the tables used in the database is as follows:

1. The MetaContactGroups are stored in a table named "METAGROUP". It
contains the following fields:

a."NAME" -the MetaContactGroup's Name

b."UID" - the MetaContactGroup's UID

c. "PERSISTENT_DATA" - the MetaContactGroup's Pessistent Data

d."GROUP_UID"- the MetaContactGroup's Parent Group UID

2 The ProtoContactGroups are stored in a table named "PROTOGROUP". It
contains the following fields:

a."UID"- the ProtoContactGroup's UID

b."ACCOUNT_ID" - the ProtoContactGroup's Account ID

c. "PARENT_UID"- the ProtoContactGroup's Parent

d. "PERSISTENT_DATA" - the ProtoContactGroup's Persistent Data

e. "GROUP_UID" - the ProtoContactGroup's Parent Group UID

3 The MetaContacts are stored in a table named "METACONTACT". It
contains the following fields:

a. "UID" - the MetaContacts's UID

b. "DISPLAY_NAME" - the MetaContacts's Display Name

c. "DETAIL" - the MetaContacts's Details

d. "GROUP_UID" - the MetaContacts's Parent Group UID

4 The ProtoContacts are stored in a table named "CONTACT". It
contains the following fields:

a. "CONTACT" - the ProtoContacts

b. "ADDRESS" - the ProtoContact's Address

c. "ACCOUNT_ID" - the ProtoContact's Account ID

d. "PERSISTENT_DATA" - the ProtoContact's Persistent Data

e. "METACONTACT_UID" - the ProtoContact's Parent MetaContact UID

f. "PROTOGROUP_UID" - the ProtoContact's Parent ProtoGroup UID

g. "GROUP_UID" - the ProtoContact's Parent Group UID

Regards

Ajay

On Sat, Jul 25, 2009 at 3:08 PM, AJAY >>>>>>>>> CHHATWAL<ajay.chhatwal.cse07@itbhu.ac.in> wrote:

Hi all

As a part of my GSoC project, I have developed a new meta contact
list
service implementation based on the database service developed by me
earlier and have committed the code to my branch.

To store the contact list (which naturally has a hierarchical
structure) in tables, I have used four tables to store
MetaContactGroups,MetaContacts,ProtoContactGroups and ProtoContacts
separately.To depict the relation between these (parent child
relationships b/w XML nodes), the child records maintain the UIDs of
their parent groups, protogroups or metacontacts as applicable.

Kindly give your comments and suggestions regarding the new impl.

Regards

Ajay

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Hi all

I have modified the meta contact list impl to store metacontact
details in a separate table and commited the code to my branch.

The modified structure of the tables used to store the contact list in
the database is as follows:

1. The MetaContactGroups are stored in a table named "METAGROUP". It
contains the following fields:

a."NAME" -the MetaContactGroup's Name

b."UID" - the MetaContactGroup's UID

c. "PERSISTENT_DATA" - the MetaContactGroup's Pessistent Data

d."GROUP_UID"- the MetaContactGroup's Parent Group UID

2 The ProtoContactGroups are stored in a table named "PROTOGROUP". It
contains the following fields:

  a."UID"- the ProtoContactGroup's UID

  b."ACCOUNT_ID" - the ProtoContactGroup's Account ID

  c. "PARENT_UID"- the ProtoContactGroup's Parent

  d. "PERSISTENT_DATA" - the ProtoContactGroup's Persistent Data

  e. "GROUP_UID" - the ProtoContactGroup's Parent Group UID

3 The MetaContacts are stored in a table named "METACONTACT". It
contains the following fields:

  a. "UID" - the MetaContacts's UID

  b. "DISPLAY_NAME" - the MetaContacts's Display Name

4 The MetaContact Details are stored in a table named "DETAILS". It
contains the following fields:

a. "METACONATCT_UID" - the MetaContact UID

b. "NAME" - the Detail Name

c. "VALUE" - the Detail Value

5 The MetaContacts and their Parent MetaGroups are stored in a
table named "RELATION". It contains the following fields:

  a. "METACONATCT_UID" - the MetaContacts's UID

  b. "PARENT_METAGROUP_UID" - the parent MetaGroup's UID

6 The ProtoContacts are stored in a table named "CONTACT". It
contains the following fields:

a. "CONTACT" - the ProtoContacts

b. "ADDRESS" - the ProtoContact's Address

c. "ACCOUNT_ID" - the ProtoContact's Account ID

d. "PERSISTENT_DATA" - the ProtoContact's Persistent Data

e. "METACONTACT_UID" - the ProtoContact's Parent MetaContact UID

f. "PROTOGROUP_UID" - the ProtoContact's Parent ProtoGroup UID

g. "GROUP_UID" - the ProtoContact's Parent Group UID

Regards

Ajay

···

On 7/28/09, AJAY CHHATWAL <ajay.chhatwal.cse07@itbhu.ac.in> wrote:

Hi all

The modified structure of the tables used to store the contact list in
the database is as follows:

1. The MetaContactGroups are stored in a table named "METAGROUP". It
contains the following fields:

a."NAME" -the MetaContactGroup's Name

b."UID" - the MetaContactGroup's UID

c. "PERSISTENT_DATA" - the MetaContactGroup's Pessistent Data

d."GROUP_UID"- the MetaContactGroup's Parent Group UID

2 The ProtoContactGroups are stored in a table named "PROTOGROUP". It
contains the following fields:

   a."UID"- the ProtoContactGroup's UID

   b."ACCOUNT_ID" - the ProtoContactGroup's Account ID

   c. "PARENT_UID"- the ProtoContactGroup's Parent

   d. "PERSISTENT_DATA" - the ProtoContactGroup's Persistent Data

   e. "GROUP_UID" - the ProtoContactGroup's Parent Group UID

3 The MetaContacts are stored in a table named "METACONTACT". It
contains the following fields:

   a. "UID" - the MetaContacts's UID

   b. "DISPLAY_NAME" - the MetaContacts's Display Name

   c. "DETAIL" - the MetaContacts's Details

4 The MetaContacts and their Parent MetaGroups are stored in a
table named "RELATION". It contains the following fields:

   a. "METACONATCT_UID" - the MetaContacts's UID

   b. "PARENT_METAGROUP_UID" - the parent MetaGroup's UID

5 The ProtoContacts are stored in a table named "CONTACT". It
contains the following fields:

  a. "CONTACT" - the ProtoContacts

  b. "ADDRESS" - the ProtoContact's Address

  c. "ACCOUNT_ID" - the ProtoContact's Account ID

  d. "PERSISTENT_DATA" - the ProtoContact's Persistent Data

  e. "METACONTACT_UID" - the ProtoContact's Parent MetaContact UID

  f. "PROTOGROUP_UID" - the ProtoContact's Parent ProtoGroup UID

  g. "GROUP_UID" - the ProtoContact's Parent Group UID

Regards

Ajay

On Tue, Jul 28, 2009 at 3:12 PM, Emil Ivov<emcho@sip-communicator.org> > wrote:

Hey ajay,

AJAY CHHATWAL wrote:

Hi emil

I have modified the contact list implementation to allow the
MetaContacts to have multiple parent MetaContactGroups by using a
separate relation table and have renamed the Constant desired by you
and have committed the code to my branch

Thanks! Maybe you'd like to post an updated design here?

To all GSoC students: Folks, it probably appears natural to you that
people here would rush to check out your branches every time you post a
change. Some may actually do that, like for example your mentors,
however if you want more people to follow your work then you should make
it easy for them. One easy way to do that is post summaries here and
tell others about what your changes are about.

Cheers
Emil

Regards

Ajay

On Sun, Jul 26, 2009 at 5:17 PM, AJAY >>> CHHATWAL<ajay.chhatwal.cse07@itbhu.ac.in> wrote:

Hi emil

I understand your point now.Will try to modify my impl.

Regards

Ajay

On Sun, Jul 26, 2009 at 5:09 PM, Emil Ivov<emcho@sip-communicator.org> >>>> wrote:

Oh, I was thinking of sth quite simple really. A 2-column table,
mapping
contacts to parent groups, should do the job.

Wdyt?
Emil

--sent from my mobile

On 26 juil. 2009, at 13:23, AJAY CHHATWAL >>>>> <ajay.chhatwal.cse07@itbhu.ac.in> >>>>> wrote:

Hi Emil,

Could you please elaborate a bit on the structure of an extra
relation
table.

Regards

Ajay

On Sun, Jul 26, 2009 at 12:39 AM, Emil >>>>>> Ivov<emcho@sip-communicator.org> >>>>>> wrote:

Hey Ajay,

Hi emil

On 7/25/09, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Ajay,

Looks reasonable. A few comments though:

* Protocols like XMPP and MSN allow having one and the same contact
in
multiple groups. We don't currently support this and always pick
one
group, but we will have to fix it one day.

It may therefore be worth taking the case into account in the
table
design. Possibly by moving the relation to a separate table.

I believe that current design of the tables will support the
behavior
mentioned above by making simple changes like parsing the Parent
Group
as a a list of strings separated by a special unicode
character.This
would be more efficient than moving the relation into a seperate
table.

This would work indeed, however, we are moving away from xml so that
we
don't have to do any parsing in such sitiations, so I'd prefer we
went
for
an extra relation table. This should also improve contact loopup in
cases
of
multiple parents and would spare us the need to implement
shieldingmechanisms.

* I don't quite understand the need of storing the parent meta
group in
the Contacts table. Wouldn't it be enough to only have the parent
proto
group?

Yes, it would be enough to only have the parent proto group.I have
included the parent meta group in order to make group operations
such as
deletion etc. easier .

I am not sure I understand how this would improve group deletion. If
you
are
to remove a meta group you'd have to lookup and remove all its
protogroups
anyway.

* In the METAGROUP group table, could you please rename the
GROUP_UID
column to PARENT_METAGROUP_UID?

* In the PROTOGROUP table, could you please rename the GROUP_UID
and
the
PARENT_UID to PARENT_PRTOGROUP_UID and PARENT_METAGROUP_UID (Not
necessarily in that order cause I couldn't really figure what they
correspond to based on their descriptions).

I would rename them as desired by you.

* There could be multiple DETAIL's per meta contact so it might be
worth
moving those to a separate table as well.

This is not required as the details are stored as a hash table in
the
form
of a Java object in the database table.

Is there any specific reason for this? Why would we want to
absolutely
deserialize egery time we need a single detail?

Once again, replacing xml storage with a db is a serious effort
anyway so
lets try to benefit from it as best as we can.

Emil

--sent from my mobile

That's all I can think of right now. Let me know if you have any
questiosn!

Cheers
Emil

Hope this answers your questions.Let me know if have any more
comments
or questions

Regards

Ajay

AJAY CHHATWAL wrote:

Hi all

The structure of the tables used in the database is as follows:

1. The MetaContactGroups are stored in a table named "METAGROUP".
It
contains the following fields:

a."NAME" -the MetaContactGroup's Name

b."UID" - the MetaContactGroup's UID

c. "PERSISTENT_DATA" - the MetaContactGroup's Pessistent Data

d."GROUP_UID"- the MetaContactGroup's Parent Group UID

2 The ProtoContactGroups are stored in a table named
"PROTOGROUP". It
contains the following fields:

a."UID"- the ProtoContactGroup's UID

b."ACCOUNT_ID" - the ProtoContactGroup's Account ID

c. "PARENT_UID"- the ProtoContactGroup's Parent

d. "PERSISTENT_DATA" - the ProtoContactGroup's Persistent Data

e. "GROUP_UID" - the ProtoContactGroup's Parent Group UID

3 The MetaContacts are stored in a table named "METACONTACT". It
contains the following fields:

a. "UID" - the MetaContacts's UID

b. "DISPLAY_NAME" - the MetaContacts's Display Name

c. "DETAIL" - the MetaContacts's Details

d. "GROUP_UID" - the MetaContacts's Parent Group UID

4 The ProtoContacts are stored in a table named "CONTACT". It
contains the following fields:

a. "CONTACT" - the ProtoContacts

b. "ADDRESS" - the ProtoContact's Address

c. "ACCOUNT_ID" - the ProtoContact's Account ID

d. "PERSISTENT_DATA" - the ProtoContact's Persistent Data

e. "METACONTACT_UID" - the ProtoContact's Parent MetaContact
UID

f. "PROTOGROUP_UID" - the ProtoContact's Parent ProtoGroup UID

g. "GROUP_UID" - the ProtoContact's Parent Group UID

Regards

Ajay

On Sat, Jul 25, 2009 at 3:08 PM, AJAY >>>>>>>>>> CHHATWAL<ajay.chhatwal.cse07@itbhu.ac.in> wrote:

Hi all

As a part of my GSoC project, I have developed a new meta
contact
list
service implementation based on the database service developed by
me
earlier and have committed the code to my branch.

To store the contact list (which naturally has a hierarchical
structure) in tables, I have used four tables to store
MetaContactGroups,MetaContacts,ProtoContactGroups and
ProtoContacts
separately.To depict the relation between these (parent child
relationships b/w XML nodes), the child records maintain the UIDs
of
their parent groups, protogroups or metacontacts as applicable.

Kindly give your comments and suggestions regarding the new
impl.

Regards

Ajay

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE:
+33.1.77.62.43.30
http://sip-communicator.org FAX:
+33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#11

Hi all

I have replaced the use of GROUP in all column names by PROTOGROUP and
METAGROUP ,as appropriate, to avoid any ambiguity.

Regards

Ajay

···

On Tue, Jul 28, 2009 at 5:32 PM, AJAY CHHATWAL<ajay.chhatwal.cse07@itbhu.ac.in> wrote:

Hi all

I have modified the meta contact list impl to store metacontact
details in a separate table and commited the code to my branch.

The modified structure of the tables used to store the contact list in
the database is as follows:

1. The MetaContactGroups are stored in a table named "METAGROUP". It
contains the following fields:

a."NAME" -the MetaContactGroup's Name

b."UID" - the MetaContactGroup's UID

c. "PERSISTENT_DATA" - the MetaContactGroup's Pessistent Data

d."GROUP_UID"- the MetaContactGroup's Parent Group UID

2 The ProtoContactGroups are stored in a table named "PROTOGROUP". It
contains the following fields:

a."UID"- the ProtoContactGroup's UID

b."ACCOUNT_ID" - the ProtoContactGroup's Account ID

c. "PARENT_UID"- the ProtoContactGroup's Parent

d. "PERSISTENT_DATA" - the ProtoContactGroup's Persistent Data

e. "GROUP_UID" - the ProtoContactGroup's Parent Group UID

3 The MetaContacts are stored in a table named "METACONTACT". It
contains the following fields:

a. "UID" - the MetaContacts's UID

b. "DISPLAY_NAME" - the MetaContacts's Display Name

4 The MetaContact Details are stored in a table named "DETAILS". It
contains the following fields:

a. "METACONATCT_UID" - the MetaContact UID

b. "NAME" - the Detail Name

c. "VALUE" - the Detail Value

5 The MetaContacts and their Parent MetaGroups are stored in a
table named "RELATION". It contains the following fields:

a. "METACONATCT_UID" - the MetaContacts's UID

b. "PARENT_METAGROUP_UID" - the parent MetaGroup's UID

6 The ProtoContacts are stored in a table named "CONTACT". It
contains the following fields:

a. "CONTACT" - the ProtoContacts

b. "ADDRESS" - the ProtoContact's Address

c. "ACCOUNT_ID" - the ProtoContact's Account ID

d. "PERSISTENT_DATA" - the ProtoContact's Persistent Data

e. "METACONTACT_UID" - the ProtoContact's Parent MetaContact UID

f. "PROTOGROUP_UID" - the ProtoContact's Parent ProtoGroup UID

g. "GROUP_UID" - the ProtoContact's Parent Group UID

Regards

Ajay

On 7/28/09, AJAY CHHATWAL <ajay.chhatwal.cse07@itbhu.ac.in> wrote:

Hi all

The modified structure of the tables used to store the contact list in
the database is as follows:

1. The MetaContactGroups are stored in a table named "METAGROUP". It
contains the following fields:

a."NAME" -the MetaContactGroup's Name

b."UID" - the MetaContactGroup's UID

c. "PERSISTENT_DATA" - the MetaContactGroup's Pessistent Data

d."GROUP_UID"- the MetaContactGroup's Parent Group UID

2 The ProtoContactGroups are stored in a table named "PROTOGROUP". It
contains the following fields:

a."UID"- the ProtoContactGroup's UID

b."ACCOUNT_ID" - the ProtoContactGroup's Account ID

c. "PARENT_UID"- the ProtoContactGroup's Parent

d. "PERSISTENT_DATA" - the ProtoContactGroup's Persistent Data

e. "GROUP_UID" - the ProtoContactGroup's Parent Group UID

3 The MetaContacts are stored in a table named "METACONTACT". It
contains the following fields:

a. "UID" - the MetaContacts's UID

b. "DISPLAY_NAME" - the MetaContacts's Display Name

c. "DETAIL" - the MetaContacts's Details

4 The MetaContacts and their Parent MetaGroups are stored in a
table named "RELATION". It contains the following fields:

a. "METACONATCT_UID" - the MetaContacts's UID

b. "PARENT_METAGROUP_UID" - the parent MetaGroup's UID

5 The ProtoContacts are stored in a table named "CONTACT". It
contains the following fields:

a. "CONTACT" - the ProtoContacts

b. "ADDRESS" - the ProtoContact's Address

c. "ACCOUNT_ID" - the ProtoContact's Account ID

d. "PERSISTENT_DATA" - the ProtoContact's Persistent Data

e. "METACONTACT_UID" - the ProtoContact's Parent MetaContact UID

f. "PROTOGROUP_UID" - the ProtoContact's Parent ProtoGroup UID

g. "GROUP_UID" - the ProtoContact's Parent Group UID

Regards

Ajay

On Tue, Jul 28, 2009 at 3:12 PM, Emil Ivov<emcho@sip-communicator.org> >> wrote:

Hey ajay,

AJAY CHHATWAL wrote:

Hi emil

I have modified the contact list implementation to allow the
MetaContacts to have multiple parent MetaContactGroups by using a
separate relation table and have renamed the Constant desired by you
and have committed the code to my branch

Thanks! Maybe you'd like to post an updated design here?

To all GSoC students: Folks, it probably appears natural to you that
people here would rush to check out your branches every time you post a
change. Some may actually do that, like for example your mentors,
however if you want more people to follow your work then you should make
it easy for them. One easy way to do that is post summaries here and
tell others about what your changes are about.

Cheers
Emil

Regards

Ajay

On Sun, Jul 26, 2009 at 5:17 PM, AJAY >>>> CHHATWAL<ajay.chhatwal.cse07@itbhu.ac.in> wrote:

Hi emil

I understand your point now.Will try to modify my impl.

Regards

Ajay

On Sun, Jul 26, 2009 at 5:09 PM, Emil Ivov<emcho@sip-communicator.org> >>>>> wrote:

Oh, I was thinking of sth quite simple really. A 2-column table,
mapping
contacts to parent groups, should do the job.

Wdyt?
Emil

--sent from my mobile

On 26 juil. 2009, at 13:23, AJAY CHHATWAL >>>>>> <ajay.chhatwal.cse07@itbhu.ac.in> >>>>>> wrote:

Hi Emil,

Could you please elaborate a bit on the structure of an extra
relation
table.

Regards

Ajay

On Sun, Jul 26, 2009 at 12:39 AM, Emil >>>>>>> Ivov<emcho@sip-communicator.org> >>>>>>> wrote:

Hey Ajay,

Hi emil

On 7/25/09, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Ajay,

Looks reasonable. A few comments though:

* Protocols like XMPP and MSN allow having one and the same contact
in
multiple groups. We don't currently support this and always pick
one
group, but we will have to fix it one day.

It may therefore be worth taking the case into account in the
table
design. Possibly by moving the relation to a separate table.

I believe that current design of the tables will support the
behavior
mentioned above by making simple changes like parsing the Parent
Group
as a a list of strings separated by a special unicode
character.This
would be more efficient than moving the relation into a seperate
table.

This would work indeed, however, we are moving away from xml so that
we
don't have to do any parsing in such sitiations, so I'd prefer we
went
for
an extra relation table. This should also improve contact loopup in
cases
of
multiple parents and would spare us the need to implement
shieldingmechanisms.

* I don't quite understand the need of storing the parent meta
group in
the Contacts table. Wouldn't it be enough to only have the parent
proto
group?

Yes, it would be enough to only have the parent proto group.I have
included the parent meta group in order to make group operations
such as
deletion etc. easier .

I am not sure I understand how this would improve group deletion. If
you
are
to remove a meta group you'd have to lookup and remove all its
protogroups
anyway.

* In the METAGROUP group table, could you please rename the
GROUP_UID
column to PARENT_METAGROUP_UID?

* In the PROTOGROUP table, could you please rename the GROUP_UID
and
the
PARENT_UID to PARENT_PRTOGROUP_UID and PARENT_METAGROUP_UID (Not
necessarily in that order cause I couldn't really figure what they
correspond to based on their descriptions).

I would rename them as desired by you.

* There could be multiple DETAIL's per meta contact so it might be
worth
moving those to a separate table as well.

This is not required as the details are stored as a hash table in
the
form
of a Java object in the database table.

Is there any specific reason for this? Why would we want to
absolutely
deserialize egery time we need a single detail?

Once again, replacing xml storage with a db is a serious effort
anyway so
lets try to benefit from it as best as we can.

Emil

--sent from my mobile

That's all I can think of right now. Let me know if you have any
questiosn!

Cheers
Emil

Hope this answers your questions.Let me know if have any more
comments
or questions

Regards

Ajay

AJAY CHHATWAL wrote:

Hi all

The structure of the tables used in the database is as follows:

1. The MetaContactGroups are stored in a table named "METAGROUP".
It
contains the following fields:

a."NAME" -the MetaContactGroup's Name

b."UID" - the MetaContactGroup's UID

c. "PERSISTENT_DATA" - the MetaContactGroup's Pessistent Data

d."GROUP_UID"- the MetaContactGroup's Parent Group UID

2 The ProtoContactGroups are stored in a table named
"PROTOGROUP". It
contains the following fields:

a."UID"- the ProtoContactGroup's UID

b."ACCOUNT_ID" - the ProtoContactGroup's Account ID

c. "PARENT_UID"- the ProtoContactGroup's Parent

d. "PERSISTENT_DATA" - the ProtoContactGroup's Persistent Data

e. "GROUP_UID" - the ProtoContactGroup's Parent Group UID

3 The MetaContacts are stored in a table named "METACONTACT". It
contains the following fields:

a. "UID" - the MetaContacts's UID

b. "DISPLAY_NAME" - the MetaContacts's Display Name

c. "DETAIL" - the MetaContacts's Details

d. "GROUP_UID" - the MetaContacts's Parent Group UID

4 The ProtoContacts are stored in a table named "CONTACT". It
contains the following fields:

a. "CONTACT" - the ProtoContacts

b. "ADDRESS" - the ProtoContact's Address

c. "ACCOUNT_ID" - the ProtoContact's Account ID

d. "PERSISTENT_DATA" - the ProtoContact's Persistent Data

e. "METACONTACT_UID" - the ProtoContact's Parent MetaContact
UID

f. "PROTOGROUP_UID" - the ProtoContact's Parent ProtoGroup UID

g. "GROUP_UID" - the ProtoContact's Parent Group UID

Regards

Ajay

On Sat, Jul 25, 2009 at 3:08 PM, AJAY >>>>>>>>>>> CHHATWAL<ajay.chhatwal.cse07@itbhu.ac.in> wrote:

Hi all

As a part of my GSoC project, I have developed a new meta
contact
list
service implementation based on the database service developed by
me
earlier and have committed the code to my branch.

To store the contact list (which naturally has a hierarchical
structure) in tables, I have used four tables to store
MetaContactGroups,MetaContacts,ProtoContactGroups and
ProtoContacts
separately.To depict the relation between these (parent child
relationships b/w XML nodes), the child records maintain the UIDs
of
their parent groups, protogroups or metacontacts as applicable.

Kindly give your comments and suggestions regarding the new
impl.

Regards

Ajay

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE:
+33.1.77.62.43.30
http://sip-communicator.org FAX:
+33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net