Re: GSoC History plugin

Quick comments before I update the schema:

On Wed, Jun 17, 2015 at 2:24 PM, Pali Rohár <[email protected]> wrote:

> Hi,
>
> still I see there couple of problems:
>
> 1) Why is group_type needed which just specify protocol? Protocol is
> already present in messages table.
>
> 2) I would prefer to have integer primary key for groups and also
> referenced it from messages table (instead string). I would expect that
> some SQL databases could have problems to use "unknown" string type as
> primary key.
>
> 3) jabber_resource column is totally useless... first storage should be
> protocol independent and second it is resource of what? local contact?
> remote contact?
>

These were slight overlooks from me. I'll update it.


>
> 4) For me it looks like that some column names are too long (like
> remote_contact_name) and basically names are not consistent...
> Like local_id and local_contact_name... Try to "clean-up" names.
>


Yes...I will use, as you suggest below: from_id, to_id, from_name, to_name


>
> 5) Have you looked at Kopete::Message class deeply?
>
> http://api.kde.org/4.x-api/kdenetwork-apidocs/kopete/libkopete/html/classKopete_1_1Message.html
> E.g direction can be also internal. Why did you not stored MessageState
> and MessageType? I do not see discussion about it...
>
>
Noted. I will add them.


> 6) How will be handled (future) message editation? For this purpose
> there is Kopete::Message::id() function which returns unique (I think
> per chat session) number.
>


We will have to discuss this more, I think. We would have to save the
sessions.


>
> 7) I see that you completely removed subject from messages table. But
> you did not write reason? Protocols do not use it? Or do you think it is
> not needed?
>
> Btw, more often I'm using column with _id suffix as reference/foreign
> key to other table. But do not know if this is something which others
> prefer or not too...
>
> And for handling problem with jabber resource now I got this idea:
>
> What about storing this?
> * protocol
> * account
> * contact
> * from_id
> * to_id
> * from_name
> * to_name
>
> (from|to)_id will be full protcol *dependent* identifier, so jabber can
> store full JID "user@host/resource" and account can represent your
> local_id and contact your remote_id.
>
> But do not know now... Any idea? Make sense? At least it could be needed
> to modify it to work with multi user group chat correctly...
>


Yes this makes sense.


>
> --
> Pali Rohár
> [email protected]
> _______________________________________________
> kopete-devel mailing list
> [email protected]
> https://mail.kde.org/mailman/listinfo/kopete-devel
>



-- 
Thanks,
Joshua

_______________________________________________
kopete-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kopete-devel