I modified MC spec with my proposed Chandler system. You can see it there: <a href="http://projects.collabora.co.uk/~xclaesse/mc/doc.html">http://projects.collabora.co.uk/~xclaesse/mc/doc.html</a> I modified .chandler file format and org.freedesktop.Telepathy.MissionControl.ChannelHandler interface. Xavier Claessens <div>2007/10/9, Xavier Claessens <<a href="mailto:xclaesse@gmail.com">xclaesse@gmail.com</a>>: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hello, I discussed a bit with Guillaume about Tube integration in MC/Empathy while he was working on gtetrinet to use Empathy. I think we need more powerful chandler/filter system in MC. Uses cases: ---------- 1) private chat client want to be started for and receive a Text channel with an handle of type Contact and muc client wants Text channels with handle type Room. 2) Logger application wants to receive any text channel (private and muc), it wants to keep using the channel and let MC start the chat client. 3) StatusIcon and ContactList wants to receive any Text channel *before* the chat client and will tell MC when chat client can be started, like that the they can blink the icon and wait for the user to click on it before starting the chat program. StatusIcon and ContactList can be separate processes, they both need to get the channel at the same time (before chat client) and once one of them says it's ok to start the chat the other should be warned to stop blinking. 4) GTetrinet wants to receive Tubes channels and TubeID ONLY if the tube's service is "tetrinet-x". Problems I see with Nokia's MC: ------------------------------ - I can't register a chandler for a given handler+channel type. Makes uses case 1 impossible. - Use case 2 is possible with a filter but the logger process needs to be started before to register the filter and if MC exits because we go offline the filter needs to be registered again once MC restarts (How logger can know that?). - Use case 3 is not possible. We can register 2 filters but they won't get the channel at the same time, one will be started before the other and will wait until the user click on the icon and then MC will start the second and wait again for the user to click on it. MC should start all filters with the same priority at the same time and wait until one of them says the channel can be dispatched, and MC should tell other filters that it's being dispatched so they can stop blink the icon. - Use case 4 is not possible because we can't register a chandler for a given tube service.   I know that NMC has a plugin system that should solve most of those problems, but I don't like the idea of writing MC plugins. Chandlers should work with any MC implementation and a bad written chandler shouldn't be able to make MC crash so it shouldn't be linked into MC's daemon. Ideas to solve that: -------------------   A I already said for the MC spec standardisation I think we shouldn't separate the chandler and filter concepts, in the end both are programs that needs to be started when a channel is created. I'll give some ideas for a chandler system that do also filter's job. Chandler programs need to install a .chandler file containing: - The DBus service of the the chandler program to be started by MC. - The channel type the chandler wants and/or the handle type. - Optionally the tube service (only if the channel type is Tubes). If it's omitted and the channel type is Tubes MC will start the service for all Tubes channels but not for each new TubeID created on that channel. - A priority number. If at some point more than one chandler should be started, they get started in the order of priority. Each time MC waits for the chandler to tell it's ok to dispatch before starting chandlers with lower priority. If a chandler says it's not OK to dispatch, MC Closes the channel and don't start other chandlers. In case of equality MC starts all equal chandlers and waits until one of them says it's ok to dispatch, it tells others started chandlers that the channel is being dispatched and start the next chandler with lower priority. If the lowest priority chandler (in most cases that's the chat-ui) tells to dispatch and there is no remaining chandlers, MC closes the channel.   So programs that wants to handle a channel have to provide a .chandler file, a .service file for DBus and once it gets started it must register a DBus object providing a standardised interface. This interface needs: - A "HandleChannel" method that MC will call to give the TpChan and TpConn objects that needs to be handled, a dictionary with some additional information for example if it's a tube chandler we'll have ("service", "tetrinet-x") and ("TubeId", 12) pairs, and a unique ChandlerID number. - A "Process" method that MC will call to tell the chandler the channel has been dispatched to a lower priority chandler (for use case 3). This method has in parameters the same ChandlerID than the one given in HandleChannel. - A "Dispatch" signal that the chandler will emit when it's OK to dispatch. It as in parameters the ChandlerID given in HandleChannel. If it's the StatusIcon chandler and the user says he don't want to accept the chat, the chandler Closes the channel and don't emit the signal, MC should listen to "Closed" signal on channels being dispatched and remove them it they get closed. Comments are welcome, I think we can discuss that and include it in MC's standardised spec. I would be really happy if it could be implemented in Nokia's MC. Thanks, Xavier Claessens. </blockquote></div>