On Thursday 18 June 2015 15:57:45 Joshua Joseph wrote:
> On Thu, Jun 18, 2015 at 1:35 PM, Pali Rohár <pali.ro...@gmail.com>
> wrote:
> > 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.
>
> OK I will work on making them clearer.
>
> I intended for the account field to be protocol
> dependant, as you had said earlier, so that jabber can store full
> JID.
> But then you cannot show history! You will get Kopete::Acount::accountId and you cannot match anything in database against accountId if you store protocol dependent string into database... This is no go way. You will select Kopete::Contact object, from it you will ask for contactId() and this information you will use for searching for history messages in database. If you do not store contactId() into database how other you want to search for history which belongs to particular Kopete::Contact object? -- Pali Rohár pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
