[crossfire] channels

[Mark Wedel]

     tchize at myrealbox.com
     
      wrote:
>
     
     
     >
     
      nope, peoples only have one field to update it's the book->msg field.
     
     >
     
      The server just present data differently depending on the command used to send 
     
     >
     
      data (draw_info or draw_info_ext)
     
     >
     
      in fact server does this:
     
     >
     
      strncpy(buf,sizeof(buf),"You open the %s and star reading...
     
     >
     
      \n%s",ob->name,ob->msg);
     
     >
     
     
     >
     
      Something similar is done for nicebuf. The server will also have to strip out 
     
     >
     
      media tags before sending using the draw_info command (for old clients)
     
     
  This has to be done at load time then - if we have to examine every message we 
send to a client to see if it has tags and then strip out those tags, I'd see 
this quickly become a very costly operation.

>>
     
       I hope on #2 you are using the formatting features the GTK already has
     
     >>
     
     built in.  If so, then it makes life much easier (it'd be really stupid to
     
     >>
     
     have to write our own parser for that when GTK provides one for us)
     
     >
     
     
     >
     
     
     >
     
      working with gtk1, all i saw was samething called gtk-html, which is an 
     
     >
     
      extension not include with the main gtk code, and i doubt it will work for 
     
     >
     
      windows version :/
     
     >
     
     
     >
     
      i choos to use something easy to handle (no closing tag, a tag just set a 
     
     >
     
      value, there is no such thing as [normal]blabla[hand]foo-bar[/hand]other 
     
     >
     
      blabla[/normal]
     
     >
     
     
     >
     
      Parsing is quite straight forward anddoesn't involve complicated things.
     
     
  I think I was looking at the pango parser:
     
     http://www.gtk.org/api/2.6/pango/PangoMarkupFormat.html
     
     

  This is a bit more complicated in its format, but then integrates very simply 
into the client.

  It just strikes me as stupid to write our own parser when there are perfectly 
good ones out there.  Aside from the initial effort, you are then likely to get 
into the case of features people perhaps want in the future, so what is right 
now a simple parser may in the end become pretty complicated.

>
     
     
     >
     
     
     >>
     
       I'd personally like to see full documentation for the 'drawinfo_ext'
     
     >>
     
     command - the docs that will make it into the protocol file.  Coding
     
     >>
     
     practices for crossfire are that the protocol changes are to have been
     
     >>
     
     properly documented and sent to the mailing list for discussion with plenty
     
     >>
     
     of advance notice before such changes are made to CVS.
     
     >>
     
     
     >
     
     
     >
     
     
     >
     
      sure, there are descriptions in protocol file
     
     
  There is nothing in the protocol file right now about your drawinfo_ext 
command.  Updating that file the same time you commit the rest of the changes is 
not considered advanced notice and is not acceptable practice.

>>
     
     
     >>
     
     drawinfo2 <formattype><msgtype><msgsubtype><color><message>
     
     >>
     
     
     >>
     
       where formattype descirbes the format of the message (text, binary data,
     
     >>
     
     text formatted in 3 rows, text formatted for ...)
     
     >>
     
     
     >>
     
       msgtype helps identify the type of message for sorting and preference
     
     >>
     
     purposes. msgsubtype is finer control.
     
     >>
     
     color is color of message - probably obsolete because that will be a client
     
     >>
     
     preference based on previous fields.
     
     >>
     
     
     >>
     
       The advantage of having formattype as the key value is that there
     
     >>
     
     probably isn't a need to have too many different format types.  And
     
     >>
     
     regardless of the remaining fields, the client could display the data if it
     
     >>
     
     understands the format type (if it doesn't, it probably shouldn't try).
     
     >>
     
     
     >
     
     
     >
     
     
     >
     
      msgtype, because it regroups things presenting the same way, does inherently 
     
     >
     
      have a format.
     
     >
     
      Client must request deliberatly a setup for each msgtype it support  to be 
     
     >
     
      send by server, so no suprises in format.
     
     
  The problem with that is I can certainly see new msgtypes added with a format 
that is very simple and every client would understand.  Yet if the client has to 
explicity understand all the msgtypes, it means it has to get the information in 
the old format (while the client may not know the msgtype, and thus not have any 
real idea of what tab to put it into, it is perfectly capable in knowing how to 
display it).

  So to me, it makes sense to seperate those two pieces - have a formattype that 
says how to display this, and a msgtype that says what type of message it is so 
the client knows what tab to display it in (or other special operations).