partysip-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Partysip-dev] several questions


From: Stefan Fritzsche
Subject: [Partysip-dev] several questions
Date: Tue, 11 Nov 2003 17:00:49 +0100 (MET)

Hello Aymeric,


I have some questions, as usual.

I have problems understanding the partysip-architecture:

  1) Why does partysip use Multithreading?
      Some time ago you mentioned that callbacks are
      protected by mutexes, so that they can't be
      executed parallel. So I don't see any advantage
      using different threads for each module.

  2) Why is the "record-route"-feature not integrated
      in the partysip-core or sfp-module? Having this
      feature spread over different plugins is really
      confusing.


Furthermore there are some implementation specific points:

  3) Giving each plugin the option to "mandate" a
      request is confusing and makes it hard to write
      additional plugins.
      I think it would be better to let all plugins do their
      job, and collect each plugin's opinion, whether the
      request could be processed success-fully or not.
      Additionally each plugin should have access to all
      status returned by other plugins before.

      E.g. this would make it much easier to let a plugin
      perform a specific task, if the callee of an Invite is
      available. Currently this is not possible, because
      the localdb-plugin mandates requests if a location
      is found.
      This particular problem is really anoying ... if localdb
      finds a location, following callbacks will no be processed,
      and if you place your new callback before localdb's
      callback, you do not know if the callee of an Invite is
      available :-( 
     
      Such a problem also occurs if one tries to catch
      Re-Invites (e.g. of a three-way-conference), because
      the filter-plugin mandates requests if there is a psp-tag
      in the route-header.
      Therefore I've added my own sfp-inc-callbacks, which
      are called after each other sfp-inc-callback, even when
      the request get's mandated before. So if one defines a
      callback, as PSP_HOOK_FINAL one can catch INVITES
      after localdb found a location and catch Re-INVITES
      after filter-plugin mandated it.
      (I would please you to take a look at the patch in the
       attachment and let me know if this breaks some
       important things in partysip, that I didn't notice)


Well ... that's all.

I'm feeling better now.

(It's like in front of a self-help-group when taking the courage
to tell 'em all my problems, seeing them nodding their heads
and silently clapping after I finished disclosing my soul ...)


Best regards,
Stefan Fritzsche

PS: the patch shows the differences to the "branch_2_1_X"-
version of partysip. It also corrects a bug in psp_core2.c
line 88, which appended REALLY_LAST-sfp-inc-hooks to
the LAST-callback-list.
(to apply patch: patch -p0 < "the-patch"
 from outside of the partysip-top-dir) 


-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Attachment: partysip-2.1.X-final-hook.patch
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]