On Thursday 18 June 2015 10:58:36 Joshua Joseph wrote: > On Wed, Jun 17, 2015 at 5:27 PM, Pali Rohár <pali.ro...@gmail.com> wrote: > > > On Wednesday 17 June 2015 14:20:05 Pali Rohár wrote: > > > On Wednesday 17 June 2015 15:11:22 Joshua Joseph wrote: > > > > > 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. > > > > > > > > > > This could probably work for normal 1 vs 1 chat. For group chat it needs > > > fixing... or not ("contact" column as string identifier of group > > > chat/room)? Or maybe using separate table?? Come up with something... > > > > > > Anyway, proper SQL schema with good documentation is required. > > > > > > (And maybe invent better column name for from_id/to_id... if you want to > > > use _id suffix only for foreign keys) > > > > > > > I think that above description should work fine for 1vs1 chat, irc chat, > > jabber MUC and skype group chat too... > > > > Every time in "protocol", "account" and "contact" columns will be stored > > Kopete::Protocol::pluginId(), Kopete::Acount::accountId() and > > Kopete::Contact::contactId() (of remote contact). > > > > In case of jabber MUC in "contact" will be stored MUC room name and in > > case of IRC just irc channel (IRC server e.g. freenode is stored as > > accountId()). And for Skype as contact will be stored some unique string > > (hash?) identifier of group chat session. > > > > Make sense? Or is there any problem? Or some change is needed? > > > > Think twice! Because you are person who will implement it! > > > > To prevent showing Skype unique string (stored in "contact") I would > > propose some "group_name" (or groupchat name, or invent better name) > > column where will be stored human readable name or description of chat. > > > > Maybe merging that group name with "is_group_chat" column could be > > possible (NULL group name means message is not from multi user chat). > > > > -- > > Pali Rohár > > pali.ro...@gmail.com > > _______________________________________________ > > kopete-devel mailing list > > kopete-devel@kde.org > > https://mail.kde.org/mailman/listinfo/kopete-devel > > > > > Here is an update to the schema: > > --Groups table: > > CREATE TABLE "groups"( > "group_id" Integer Primary Key Autoincrement NOT NULL , --Unique > identifier for the group > "group_name" Text, -- The internal name of the group > "description" Text , -- A human readable description of the group > "subject" Text , -- Topic being discussed. > ); > > > -- Messages Table > CREATE TABLE "messages"( > "message_id" Integer Primary Key Autoincrement NOT NULL , --- Date and > time of the message > "timestamp" Text , "message" Text , --The content of the message > in HTML format > "protocol" Text , -- Protocol in use > "account" Text, -- Identifier of *local* account where the message belongs > "contact" Text, --If applicable, the identifier of the *remote* party > "local_name" Text , -- Human readable contact Name (Local) > "remote_name" Text , -- Human readable contact Name (Remote), if > applicable > "importance" Integer , -- (Low = 0, High = 1, Highlight = 2) > "group_id" Text , -- If this is a group message, this will hold the > group id. If null, this is not a group message > "direction" Integer , -- (Inbound = 0, Outbound = 1, Internal = 2) > "state" Integer, --(Unknown = 0, Sending = 1, Sent = 2, Error = 3) > "subject" Text -- If applicable, the subject of this message > "" > ); > > I hope it makes more sense now. >
Apparently not. Why you are proposing so non-intuitive combination of columns "contact" and "remote_name"? Without text comments nobody would be able to understand what these two columns represent something which belongs together or at least more closer... And I really do not understand from that scheme nor comments how is multi user chat stored. Also I have no idea how will be stored additional information like jabber resource. -- Pali Rohár pali.ro...@gmail.com _______________________________________________ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel