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

AJAY CHHATWAL ajay.chhatwal.cse07 at itbhu.ac.in
Tue Jul 28 11:29:03 CEST 2009


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 at 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 at 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 at 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 at sip-communicator.org>
>>> wrote:
>>>>
>>>> Hey Ajay,
>>>>
>>>>> Hi emil
>>>>>
>>>>> On 7/25/09, Emil Ivov <emcho at 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 at 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 at sip-communicator.dev.java.net
>>>>>>> For additional commands, e-mail:
>>>>>>> dev-help at sip-communicator.dev.java.net
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Emil Ivov, Ph.D.                               67000 Strasbourg,
>>>>>> Project Lead                                   France
>>>>>> SIP Communicator
>>>>>> emcho at 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 at sip-communicator.dev.java.net
>>>>>> For additional commands, e-mail: dev-help at sip-communicator.dev.java.net
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
>>>>> For additional commands, e-mail: dev-help at sip-communicator.dev.java.net
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
>>>> For additional commands, e-mail: dev-help at sip-communicator.dev.java.net
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
>>> For additional commands, e-mail: dev-help at sip-communicator.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
>> For additional commands, e-mail: dev-help at sip-communicator.dev.java.net
>>
>>
>

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





More information about the dev mailing list