[crossfire] channels

[Mark Wedel]

tchize wrote:
>
     
     
     >
     
      The patch am working on is based on a subscribe/notify paradigm, not made to 
     
     >
     
      handle channels like yours, as i think this is a different part and you are 
     
     >
     
      doing quite well in it, but made to identify all kinds of readables send to 
     
     >
     
      client by sending them with another command than draw_info. The client 
     
     >
     
      subscribe to the server for the send of specialized data. Client can 
     
     >
     
      subscribe to receiving books in a special way, subscribe to receiving signs 
     
     >
     
      in a special way, subscribe to receiving motd in a special way, ...
     
     >
     
     
     >
     
      Now, if your patch, in this part, is just about telling server 'send me or do 
     
     >
     
      not send me literature' there will be no conflict in code logic and there 
     
     >
     
      will in fact be complementarity.
     
     >
     
      But if your patch is about 'send me literature in a way so client can identify 
     
     >
     
      it as literature' there will be a conflict of use.
     
     >
     
      According to the messages on the bugtrack, you are in the first case 
     
     >
     
      (replacing the listen level to let client tell server what may and what may 
     
     >
     
      not be send), but i just want to be sure about it before your patch make his 
     
     >
     
      way to the cvs :)
     
     
  what I said in my other email sounds like it will conflict with what you are 
suggesting.  But in a project with multiple people developing, that is bound to 
happen.  I'd also think the amount of conflict would be minor, as all I'm saying 
is changing things like NDI_BLUE to NDI_LITERATURE.

  I'd like more details on what you are thinking/trying to do. 
Attaching/sending images for scrolls (in forms of maps) is a very nifty idea. 
However, to me, it seems that either the client will support displaying this 
alternate form of data or not.  It seems unlikely to me that the client could 
display an image that is part of a scroll but not a map, so having a different 
subscription method for all the possible types of messages seems like over 
complication.

  I'd suggest that there be some form of caching/client requesting the 
additional info.  That is because one could envision something like a map being 
on a scroll - you really don't want to have to download the image every time the 
player reads the scroll - the client could certainly store a copy of the image 
away someplace, and thus next time, quickly pull it from cache.  I say this 
because I'd think that things like map images will likely be in the several 
hundred pixel by several hundred pixel range, and thus take significantly more 
time to transmit than most data generated.

  I'd be interested in seeing your proposal and storing/associating this data 
with the objects in question.


>