Re: GSoC History plugin

Joshua Joseph <[email protected]>
Newsgroups gmane.comp.kde.devel.kopete
Message-ID <CAKYNVbQK_d_1_2bgpV8MbPg6HGTA4EkL3kU_AvqHyZ7ooVRe=A@mail.gmail.com>
On Thu, Jun 18, 2015 at 10:07 PM, Pali Rohár <[email protected]> wrote:

>
> > I get it now.
> >
> > We will have to store the contactId() also. I will need to get good
> > column names
> > to avoid confusion with the foreign key columns.
> >
>
> See my yesterday email where I proposed to store pluginId() as protocol,
> accounId() as account, contactId() as contact and from/to values to be
> protocol dependent.
>
> And another question: Do we need to separate table for group chat
> messages? Cannot we use some chat session identifier for each message?
>
>
That would also work. See my schema below for a one table based approach.


> If for each message we store these data:
>
> protocol independent:
>
> * protocol - Kopete::Protocol::pluginId() - not null
> * account - Kopete::Protocol::accoundId() - not null
> * direction - Kopete::Message::direction() - not null
> * contact - Kopete::Protocol::contactId()
>
> protocol dependent (all strings):
>
> * session - session identifier
> * session_name - human readable name of session
> * from - from contact identifier
> * from_name - human readable from contact name
> * to - to contact identifier
> * to_name - human readable to contact name
>

See this schema. I think it will capture all of the above.
For protocol, account and contact fields, I have used Text columns.
I am also adding a message_type column, so that we can keep track of special
messages such as room events (user join, quit etc).  Do you think that that
will be
necessary?

--messages table
CREATE TABLE "messages" (
   "message_id" Integer Primary Key Autoincrement Not Null --Unique message
identifier
   "timestamp" Text --When the message was handled
   "message" Text --HTML containing the message contents
   "protocol" Text Not Null --Protocol used (Kopete::Protocol::pluginId())
   "account" Text Not Null --Account used (Kopete::Account::accountId())
   "direction" Integer Not Null --(Inbound = 0, Outbound=1, Internal=2)
(Kopete::Message::MessageDirection)
   "importance" Integer -- (Low, Normal, Highlight) (Kopete::Message)
(Kopete::Message::MessageImportance)
   "contact" Text -- The local contact used in this message (if
applicable). (Kopete::Contact::ContactId()). If present, we know we are in
single user mode.
   "subject" Text --If applicable, this will store the subject of the
message
   "session" Text -- Internal session identifier. If this is provided, then
we know we are in multi user mode.
   "session_name" Text -- If in multi user mode, a human readable name for
the session.
   "from" Text --Internal identifier for the message sender
   "from_name" Text --Human readable name of the message sender
   "to" Text --Internal identifier for the message recipient
   "to_name" Text --Human readable name of the message recipient.
   "message_type" --The type of message. (TypeNormal, TypeAction,
TypeFileTransferRequest, TypeVoiceClipRequest)
(Kopete::Message::MessageType)
)





>
> then I think it it should work for both single user and multi user chat.
> In this case either "contact" or "session" needs to be provided to will
> be able to know to which "view" message belongs. "contact" can be used
> for single user chat (there is no problem) and room based multi user
> chat. And session (unique string identifier) can be used for multi user
> chats without rooms (e.g. Skype-like).
>
> Columns from/to can be used to store protocol dependent information
> about sender/receiver (e.g full JID for jabber) or full of contacts in
> multi user chat...
>
> Do not remember that messages are changing their state! StateSending
> will be later changed to StateSent or StateError. The only way how to
> track this information is Kopete::Message::id() function. But id is
> unique only for one running kopete instance (not after quit and start!).
> So this information cannot be stored into database, but is it needed to
> track number of message row in table (which is unique) with in-memory
> Kopete::Message::id().
>
>
>


-- 
Thanks,
Joshua

_______________________________________________
kopete-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kopete-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.