pyst-users

[Pyst-users] a comment...

[Jan M. <jpm...@gm...>]

hi,

triggered by the recent mailing list activities, i just began to scan 
the code of manager.py, and i found this:

    def event_dispatch(self):
        """This thread is responsible fore dispatching events"""

        # loop dispatching events
        while self._running.isSet():
            # get/wait for an event
            ev = self._event_queue.get()

            # if we got None as an event, we are finished
            if not ev:
                break

            # dispatch our events

            # first build a list of the functions to execute
            callbacks = self._event_callbacks.get(ev.name, [])
            callbacks.extend(self._event_callbacks.get('*', []))  # <- !!!

            # now execute the functions
            for callback in callbacks:
               if callback(ev, self):
                  break

what happens here is that the '*' callback handlers are explicitly added 
to the (mutable) list of ev.name handlers.
i haven't tried it but this should lead to problems when unsubscribing a 
'*' handler since it still remains an
ev.name handler. i suggest a list addition to prevent manipulation of 
the list of ev.name handlers:

[...]
            # first build a list of the functions to execute
            callbacks = self._event_callbacks.get(ev.name, []) + 
self._event_callbacks.get('*', [])
[...]

when i find time (might take a while), i might try and implement some 
more of the API in the Manager class for myself.

for instance, for an event/callback driven command 'Action: sippeers', i 
would implement a method that yields a set of the 'Event: PeerEntry' 
Events to spare a user the trouble of (un)subscribing a callback, making 
up ActionIds, etc.

anyone besides me interested in this, both using and reviewing it?

regards, Jan

Re: [Pyst-users] a comment...

[Stephen C. <ste...@u4...>]

Hi Jan,

I would gladly use it, as far review goes, I think I'm too new to 
asterisk for that.

Cheers,

Stephen

Jan Müller wrote:
> hi,
>
> triggered by the recent mailing list activities, i just began to scan 
> the code of manager.py, and i found this:
>
>     def event_dispatch(self):
>         """This thread is responsible fore dispatching events"""
>
>         # loop dispatching events
>         while self._running.isSet():
>             # get/wait for an event
>             ev = self._event_queue.get()
>
>             # if we got None as an event, we are finished
>             if not ev:
>                 break
>
>             # dispatch our events
>
>             # first build a list of the functions to execute
>             callbacks = self._event_callbacks.get(ev.name, [])
>             callbacks.extend(self._event_callbacks.get('*', []))  # <- !!!
>
>             # now execute the functions
>             for callback in callbacks:
>                if callback(ev, self):
>                   break
>
> what happens here is that the '*' callback handlers are explicitly added 
> to the (mutable) list of ev.name handlers.
> i haven't tried it but this should lead to problems when unsubscribing a 
> '*' handler since it still remains an
> ev.name handler. i suggest a list addition to prevent manipulation of 
> the list of ev.name handlers:
>
> [...]
>             # first build a list of the functions to execute
>             callbacks = self._event_callbacks.get(ev.name, []) + 
> self._event_callbacks.get('*', [])
> [...]
>
> when i find time (might take a while), i might try and implement some 
> more of the API in the Manager class for myself.
>
> for instance, for an event/callback driven command 'Action: sippeers', i 
> would implement a method that yields a set of the 'Event: PeerEntry' 
> Events to spare a user the trouble of (un)subscribing a callback, making 
> up ActionIds, etc.
>
> anyone besides me interested in this, both using and reviewing it?
>
> regards, Jan
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Pyst-users mailing list
> Pys...@li...
> https://lists.sourceforge.net/lists/listinfo/pyst-users
>   

Re: [Pyst-users] a comment...

[Jan M. <jpm...@gm...>]

Stephen Cattaneo schrieb:
> Hi Jan,
>
> I would gladly use it, as far review goes, I think I'm too new to 
> asterisk for that.
>
> Cheers,
>
> Stephen
>
> Jan Müller wrote:
>   
>> hi,
>>
>> triggered by the recent mailing list activities, i just began to scan 
>> the code of manager.py, and i found this:
>>
>>     def event_dispatch(self):
>>         """This thread is responsible fore dispatching events"""
>>
>>         # loop dispatching events
>>         while self._running.isSet():
>>             # get/wait for an event
>>             ev = self._event_queue.get()
>>
>>             # if we got None as an event, we are finished
>>             if not ev:
>>                 break
>>
>>             # dispatch our events
>>
>>             # first build a list of the functions to execute
>>             callbacks = self._event_callbacks.get(ev.name, [])
>>             callbacks.extend(self._event_callbacks.get('*', []))  # <- !!!
>>
>>             # now execute the functions
>>             for callback in callbacks:
>>                if callback(ev, self):
>>                   break
>>
>> what happens here is that the '*' callback handlers are explicitly added 
>> to the (mutable) list of ev.name handlers.
>> i haven't tried it but this should lead to problems when unsubscribing a 
>> '*' handler since it still remains an
>> ev.name handler. i suggest a list addition to prevent manipulation of 
>> the list of ev.name handlers:
>>
>> [...]
>>             # first build a list of the functions to execute
>>             callbacks = self._event_callbacks.get(ev.name, []) + 
>> self._event_callbacks.get('*', [])
>> [...]
>>
>> when i find time (might take a while), i might try and implement some 
>> more of the API in the Manager class for myself.
>>
>> for instance, for an event/callback driven command 'Action: sippeers', i 
>> would implement a method that yields a set of the 'Event: PeerEntry' 
>> Events to spare a user the trouble of (un)subscribing a callback, making 
>> up ActionIds, etc.
>>
>> anyone besides me interested in this, both using and reviewing it?
>>
>> regards, Jan
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
>> Don't miss this year's exciting event. There's still time to save $100. 
>> Use priority code J8TL2D2. 
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> _______________________________________________
>> Pyst-users mailing list
>> Pys...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyst-users
>>   
>>     
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Pyst-users mailing list
> Pys...@li...
> https://lists.sourceforge.net/lists/listinfo/pyst-users
>   
hi stephen,

there is a first alpha version ready. beware, it's not tested at all. if 
you wish to use or test it, please give me your mail address (or is it 
ok to paste a messy 1000-line code here?).

to whom else it may concern:

1. i implemented a metamethod which takes the api help and generates 
methods for all simple (only response, no events) api actions from it:

<code>[...,
    ('mailbox_status', 'MailboxStatus', """Action: MailboxStatus
Synopsis: Check Mailbox
Privilege: call,all
Description: Checks a voicemail account for status.
Variables: (Names marked with * are required)
  *mailbox: Full mailbox ID <mailbox>@<vm-context>
  actionid: Optional ActionID for message matching
Returns number of messages.
  Message: Mailbox Status
  Mailbox: <mailboxid>
  Waiting: <count>
""", ["mailbox", "actionid=None"]),
...]
</code)
yields
<code>
def mailbox_status(self, mailbox, actionid=None):
   [...]
   return self.send_action({'Action': 'MailboxStatus', 'mailbox': 
mailbox, 'actionid': actionid} # actionid only included if not None
</code>
so, extending it for other simple actions (e.g., "Zap..." which I did 
not implement because I have no zap module) boils down to adding some 
lines to a table. If the API doc stirngs were a little more 
standardized, one could even fully automatically parse the documentation.

2. í also implemented event callback handlers for 'SipPeers' and 
'DBGet'. the corresponding methods yield a list(Event) (method 
sip_peers) and an Event (method db_get).

regards j.

Re: [Pyst-users] a comment...

[Stephen C. <ste...@u4...>]

Hi Jan,
  Just send the file to stephen ( dot ) cattaneo ( at ) u4eatech ( dot ) com
Cheers,

Stephen

Jan Müller wrote:
> Stephen Cattaneo schrieb:
>   
>> Hi Jan,
>>
>> I would gladly use it, as far review goes, I think I'm too new to 
>> asterisk for that.
>>
>> Cheers,
>>
>> Stephen
>>
>> Jan Müller wrote:
>>   
>>     
>>> hi,
>>>
>>> triggered by the recent mailing list activities, i just began to scan 
>>> the code of manager.py, and i found this:
>>>
>>>     def event_dispatch(self):
>>>         """This thread is responsible fore dispatching events"""
>>>
>>>         # loop dispatching events
>>>         while self._running.isSet():
>>>             # get/wait for an event
>>>             ev = self._event_queue.get()
>>>
>>>             # if we got None as an event, we are finished
>>>             if not ev:
>>>                 break
>>>
>>>             # dispatch our events
>>>
>>>             # first build a list of the functions to execute
>>>             callbacks = self._event_callbacks.get(ev.name, [])
>>>             callbacks.extend(self._event_callbacks.get('*', []))  # <- !!!
>>>
>>>             # now execute the functions
>>>             for callback in callbacks:
>>>                if callback(ev, self):
>>>                   break
>>>
>>> what happens here is that the '*' callback handlers are explicitly added 
>>> to the (mutable) list of ev.name handlers.
>>> i haven't tried it but this should lead to problems when unsubscribing a 
>>> '*' handler since it still remains an
>>> ev.name handler. i suggest a list addition to prevent manipulation of 
>>> the list of ev.name handlers:
>>>
>>> [...]
>>>             # first build a list of the functions to execute
>>>             callbacks = self._event_callbacks.get(ev.name, []) + 
>>> self._event_callbacks.get('*', [])
>>> [...]
>>>
>>> when i find time (might take a while), i might try and implement some 
>>> more of the API in the Manager class for myself.
>>>
>>> for instance, for an event/callback driven command 'Action: sippeers', i 
>>> would implement a method that yields a set of the 'Event: PeerEntry' 
>>> Events to spare a user the trouble of (un)subscribing a callback, making 
>>> up ActionIds, etc.
>>>
>>> anyone besides me interested in this, both using and reviewing it?
>>>
>>> regards, Jan
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
>>> Don't miss this year's exciting event. There's still time to save $100. 
>>> Use priority code J8TL2D2. 
>>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>>> _______________________________________________
>>> Pyst-users mailing list
>>> Pys...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pyst-users
>>>   
>>>     
>>>       
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
>> Don't miss this year's exciting event. There's still time to save $100. 
>> Use priority code J8TL2D2. 
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> _______________________________________________
>> Pyst-users mailing list
>> Pys...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyst-users
>>   
>>     
> hi stephen,
>
> there is a first alpha version ready. beware, it's not tested at all. if 
> you wish to use or test it, please give me your mail address (or is it 
> ok to paste a messy 1000-line code here?).
>
> to whom else it may concern:
>
> 1. i implemented a metamethod which takes the api help and generates 
> methods for all simple (only response, no events) api actions from it:
>
> <code>[...,
>     ('mailbox_status', 'MailboxStatus', """Action: MailboxStatus
> Synopsis: Check Mailbox
> Privilege: call,all
> Description: Checks a voicemail account for status.
> Variables: (Names marked with * are required)
>   *mailbox: Full mailbox ID <mailbox>@<vm-context>
>   actionid: Optional ActionID for message matching
> Returns number of messages.
>   Message: Mailbox Status
>   Mailbox: <mailboxid>
>   Waiting: <count>
> """, ["mailbox", "actionid=None"]),
> ...]
> </code)
> yields
> <code>
> def mailbox_status(self, mailbox, actionid=None):
>    [...]
>    return self.send_action({'Action': 'MailboxStatus', 'mailbox': 
> mailbox, 'actionid': actionid} # actionid only included if not None
> </code>
> so, extending it for other simple actions (e.g., "Zap..." which I did 
> not implement because I have no zap module) boils down to adding some 
> lines to a table. If the API doc stirngs were a little more 
> standardized, one could even fully automatically parse the documentation.
>
> 2. í also implemented event callback handlers for 'SipPeers' and 
> 'DBGet'. the corresponding methods yield a list(Event) (method 
> sip_peers) and an Event (method db_get).
>
> regards j.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Pyst-users mailing list
> Pys...@li...
> https://lists.sourceforge.net/lists/listinfo/pyst-users
>   

Re: [Pyst-users] a comment...

[Jan M. <jpm...@gm...>]

Tito Garrido schrieb:
> Sorry, I didn't understand what you're trying to do... Could you explain?
i'm basically streamlining and extending the Manager class for myself, 
just wondered if anybody else is interested.

1. i fixed some minor bugs in the Manager class concerning 
(un)registering events (see my former post)

2. i wrote a "one-fits-all" method for the Manager class which takes a 
table (which is a manually edited cut-and-paste of the API command help) 
as input and generates methods like manager.ping(), 
manager.db_put(family, key, value), ... for _all_ simple manager actions 
(which have just a simple response w/o events).
i just don't have a zap module running, so i didn't implement the "Zap*" 
actions. anyway, i would really prefer an external machine-readable 
table containing all API commands, their parameters, and their 
documentation string, which is kept up-to-date by someone. Probably a 
wiki author or even the asterisk developers might be interested as well 
in a unified api command table.

3. i implemented methods sip_peers and db_get which register for the 
query result events, then unregister again and return a list of Event 
objects containing the data which was asked for.

as already said, it's all pretty alpha, but very useful for me, and i'll 
go on developing it for my needs. i passed it to stephen for a test drive.

regards j.

Re: [Pyst-users] a comment...

[Tito G. <tit...@gm...>]

Ok, can u send to me? I'm using the traditional manager.py with some new
methods like sippeers()...

On Wed, Apr 23, 2008 at 1:59 PM, Jan Müller <jpm...@gm...> wrote:

> Tito Garrido schrieb:
> > Sorry, I didn't understand what you're trying to do... Could you
> explain?
> i'm basically streamlining and extending the Manager class for myself,
> just wondered if anybody else is interested.
>
> 1. i fixed some minor bugs in the Manager class concerning
> (un)registering events (see my former post)
>
> 2. i wrote a "one-fits-all" method for the Manager class which takes a
> table (which is a manually edited cut-and-paste of the API command help)
> as input and generates methods like manager.ping(),
> manager.db_put(family, key, value), ... for _all_ simple manager actions
> (which have just a simple response w/o events).
> i just don't have a zap module running, so i didn't implement the "Zap*"
> actions. anyway, i would really prefer an external machine-readable
> table containing all API commands, their parameters, and their
> documentation string, which is kept up-to-date by someone. Probably a
> wiki author or even the asterisk developers might be interested as well
> in a unified api command table.
>
> 3. i implemented methods sip_peers and db_get which register for the
> query result events, then unregister again and return a list of Event
> objects containing the data which was asked for.
>
> as already said, it's all pretty alpha, but very useful for me, and i'll
> go on developing it for my needs. i passed it to stephen for a test drive.
>
> regards j.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Pyst-users mailing list
> Pys...@li...
> https://lists.sourceforge.net/lists/listinfo/pyst-users
>



-- 
Linux User #387870
____
_/_õ|__|
º[ .-.___.-._| . . . .
_(o).__(o).:_____

Re: [Pyst-users] a comment...

[Tito G. <tit...@gm...>]

Sorry, I didn't understand what you're trying to do... Could you explain?


On Tue, Apr 22, 2008 at 8:49 PM, Stephen Cattaneo <
ste...@u4...> wrote:

> Hi Jan,
>  Just send the file to stephen ( dot ) cattaneo ( at ) u4eatech ( dot )
> com
> Cheers,
>
> Stephen
>
> Jan Müller wrote:
> > Stephen Cattaneo schrieb:
> >
> >> Hi Jan,
> >>
> >> I would gladly use it, as far review goes, I think I'm too new to
> >> asterisk for that.
> >>
> >> Cheers,
> >>
> >> Stephen
> >>
> >> Jan Müller wrote:
> >>
> >>
> >>> hi,
> >>>
> >>> triggered by the recent mailing list activities, i just began to scan
> >>> the code of manager.py, and i found this:
> >>>
> >>>     def event_dispatch(self):
> >>>         """This thread is responsible fore dispatching events"""
> >>>
> >>>         # loop dispatching events
> >>>         while self._running.isSet():
> >>>             # get/wait for an event
> >>>             ev = self._event_queue.get()
> >>>
> >>>             # if we got None as an event, we are finished
> >>>             if not ev:
> >>>                 break
> >>>
> >>>             # dispatch our events
> >>>
> >>>             # first build a list of the functions to execute
> >>>             callbacks = self._event_callbacks.get(ev.name, [])
> >>>             callbacks.extend(self._event_callbacks.get('*', []))  # <-
> !!!
> >>>
> >>>             # now execute the functions
> >>>             for callback in callbacks:
> >>>                if callback(ev, self):
> >>>                   break
> >>>
> >>> what happens here is that the '*' callback handlers are explicitly
> added
> >>> to the (mutable) list of ev.name handlers.
> >>> i haven't tried it but this should lead to problems when unsubscribing
> a
> >>> '*' handler since it still remains an
> >>> ev.name handler. i suggest a list addition to prevent manipulation of
> >>> the list of ev.name handlers:
> >>>
> >>> [...]
> >>>             # first build a list of the functions to execute
> >>>             callbacks = self._event_callbacks.get(ev.name, []) +
> >>> self._event_callbacks.get('*', [])
> >>> [...]
> >>>
> >>> when i find time (might take a while), i might try and implement some
> >>> more of the API in the Manager class for myself.
> >>>
> >>> for instance, for an event/callback driven command 'Action: sippeers',
> i
> >>> would implement a method that yields a set of the 'Event: PeerEntry'
> >>> Events to spare a user the trouble of (un)subscribing a callback,
> making
> >>> up ActionIds, etc.
> >>>
> >>> anyone besides me interested in this, both using and reviewing it?
> >>>
> >>> regards, Jan
> >>>
> >>>
> -------------------------------------------------------------------------
> >>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> >>> Don't miss this year's exciting event. There's still time to save
> $100.
> >>> Use priority code J8TL2D2.
> >>>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> >>> _______________________________________________
> >>> Pyst-users mailing list
> >>> Pys...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/pyst-users
> >>>
> >>>
> >>>
> >>
> -------------------------------------------------------------------------
> >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> >> Don't miss this year's exciting event. There's still time to save $100.
> >> Use priority code J8TL2D2.
> >>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> >> _______________________________________________
> >> Pyst-users mailing list
> >> Pys...@li...
> >> https://lists.sourceforge.net/lists/listinfo/pyst-users
> >>
> >>
> > hi stephen,
> >
> > there is a first alpha version ready. beware, it's not tested at all. if
> > you wish to use or test it, please give me your mail address (or is it
> > ok to paste a messy 1000-line code here?).
> >
> > to whom else it may concern:
> >
> > 1. i implemented a metamethod which takes the api help and generates
> > methods for all simple (only response, no events) api actions from it:
> >
> > <code>[...,
> >     ('mailbox_status', 'MailboxStatus', """Action: MailboxStatus
> > Synopsis: Check Mailbox
> > Privilege: call,all
> > Description: Checks a voicemail account for status.
> > Variables: (Names marked with * are required)
> >   *mailbox: Full mailbox ID <mailbox>@<vm-context>
> >   actionid: Optional ActionID for message matching
> > Returns number of messages.
> >   Message: Mailbox Status
> >   Mailbox: <mailboxid>
> >   Waiting: <count>
> > """, ["mailbox", "actionid=None"]),
> > ...]
> > </code)
> > yields
> > <code>
> > def mailbox_status(self, mailbox, actionid=None):
> >    [...]
> >    return self.send_action({'Action': 'MailboxStatus', 'mailbox':
> > mailbox, 'actionid': actionid} # actionid only included if not None
> > </code>
> > so, extending it for other simple actions (e.g., "Zap..." which I did
> > not implement because I have no zap module) boils down to adding some
> > lines to a table. If the API doc stirngs were a little more
> > standardized, one could even fully automatically parse the
> documentation.
> >
> > 2. í also implemented event callback handlers for 'SipPeers' and
> > 'DBGet'. the corresponding methods yield a list(Event) (method
> > sip_peers) and an Event (method db_get).
> >
> > regards j.
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > Don't miss this year's exciting event. There's still time to save $100.
> > Use priority code J8TL2D2.
> >
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> > _______________________________________________
> > Pyst-users mailing list
> > Pys...@li...
> > https://lists.sourceforge.net/lists/listinfo/pyst-users
> >
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Pyst-users mailing list
> Pys...@li...
> https://lists.sourceforge.net/lists/listinfo/pyst-users
>



-- 
Linux User #387870
____
_/_õ|__|
º[ .-.___.-._| . . . .
_(o).__(o).:_____

Re: [Pyst-users] a comment...

[Matthew N. <mni...@di...>]

On Fri, 2008-04-18 at 23:09 +0200, Jan Müller wrote:
> hi,
> 
> triggered by the recent mailing list activities, i just began to scan 
> the code of manager.py, and i found this:
> 
>     def event_dispatch(self):
>         """This thread is responsible fore dispatching events"""
> 
>         # loop dispatching events
>         while self._running.isSet():
>             # get/wait for an event
>             ev = self._event_queue.get()
> 
>             # if we got None as an event, we are finished
>             if not ev:
>                 break
> 
>             # dispatch our events
> 
>             # first build a list of the functions to execute
>             callbacks = self._event_callbacks.get(ev.name, [])
>             callbacks.extend(self._event_callbacks.get('*', []))  # <- !!!
>
>             # now execute the functions
>             for callback in callbacks:
>                if callback(ev, self):
>                   break
> 
> what happens here is that the '*' callback handlers are explicitly added 
> to the (mutable) list of ev.name handlers.
> i haven't tried it but this should lead to problems when unsubscribing a 
> '*' handler since it still remains an
> ev.name handler. i suggest a list addition to prevent manipulation of 
> the list of ev.name handlers:
> 
> [...]
>             # first build a list of the functions to execute
>             callbacks = self._event_callbacks.get(ev.name, []) + 
> self._event_callbacks.get('*', [])
> [...]

This is a potential problem.  In theory, if I understand what you are
saying correctly, each time an event is handled the '*' callback list
should get appended to the ev.name list.

-- 
Matthew Nicholson
Digium

Re: [Pyst-users] a comment...

[Jan M. <jpm...@gm...>]

>>
>>             # first build a list of the functions to execute
>>             callbacks = self._event_callbacks.get(ev.name, [])
>>             callbacks.extend(self._event_callbacks.get('*', []))  # <- !!!

>> This is a potential problem.  In theory, if I understand what you are
>> saying correctly, each time an event is handled the '*' callback list
>> should get appended to the ev.name list.
right. an abstraction of the issue (aDict = self._event_callbacks, 'a' = 
ev.name, 'b' = '*', aList = callbacks):

 >>> aDict = {'a': [1, 2], 'b': [3]}
 >>> aList = aDict['a']
 >>> aList
[1, 2]
 >>> aList.extend(aDict['b'])
 >>> aList
[1, 2, 3]
 >>> aDict
{'a': [1, 2, 3], 'b': [3]}

i fixed this in my private version of the class Manager. I used sets.Set 
instead of lists, but that's just a minor remark.

if i'm informed correctly, you are one of the fathers of Asterisk and 
also have brought the Manager class to where it is. since i'm knitting on

i. a table-driven (and hence flexible) implementation of most (or all?) 
API commands as Manager.methods,
ii. implementing some magic class customization __methods__, and
iii. refactoring the thread loops to reach a deeper understanding of 
what's going on (I find the deeply nested while-loops a bit scary),

i wonder if you might help me on some of the following questions:

0. does anyone mind if i keep on developing that? if this is not the 
case, i'm willing to share my results, yet i'm myself a decent private 
user and do not need unconditional, 100% reliability. so i would try and 
react on bug reports, but i will not guarantee any stability whatsoever.
1. do you know how much the Python API is used, and whether backward 
compatibility is an issue?
2. as to the refactoring: do you have a test harness of your development?
3. i don't have much experience with multi-threading. can you tell me 
what the major (possibly also open) issues were/are?
4. is there a chance to obtain a normalized (machine-readable) scheme of 
the API commands and their syntax on-the-fly by asking the Asterisk/a 
website?

regards j.

Re: [Pyst-users] a comment...

[Matthew N. <mni...@di...>]

On Thu, 2008-04-24 at 22:49 +0200, Jan Müller wrote:
> >>
> >>             # first build a list of the functions to execute
> >>             callbacks = self._event_callbacks.get(ev.name, [])
> >>             callbacks.extend(self._event_callbacks.get('*', []))  # <- !!!
> 
> >> This is a potential problem.  In theory, if I understand what you are
> >> saying correctly, each time an event is handled the '*' callback list
> >> should get appended to the ev.name list.
> right. an abstraction of the issue (aDict = self._event_callbacks, 'a' = 
> ev.name, 'b' = '*', aList = callbacks):
> 
>  >>> aDict = {'a': [1, 2], 'b': [3]}
>  >>> aList = aDict['a']
>  >>> aList
> [1, 2]
>  >>> aList.extend(aDict['b'])
>  >>> aList
> [1, 2, 3]
>  >>> aDict
> {'a': [1, 2, 3], 'b': [3]}

ok

> i fixed this in my private version of the class Manager. I used sets.Set 
> instead of lists, but that's just a minor remark.
> 
> if i'm informed correctly, you are one of the fathers of Asterisk and 
> also have brought the Manager class to where it is. since i'm knitting on

Well I am sort of the defacto lead developer of pyst (not Asterisk)
which is what I think you meant.

> i. a table-driven (and hence flexible) implementation of most (or all?) 
> API commands as Manager.methods,
> ii. implementing some magic class customization __methods__, and
> iii. refactoring the thread loops to reach a deeper understanding of 
> what's going on (I find the deeply nested while-loops a bit scary),
> 
> i wonder if you might help me on some of the following questions:
> 
> 0. does anyone mind if i keep on developing that? if this is not the 
> case, i'm willing to share my results, yet i'm myself a decent private 
> user and do not need unconditional, 100% reliability. so i would try and 
> react on bug reports, but i will not guarantee any stability whatsoever.

Well the code is virtually unmaintained at the moment.  If you would
like to take over, I am fine with that.

> 1. do you know how much the Python API is used, and whether backward 
> compatibility is an issue?

I have not looked into this

> 2. as to the refactoring: do you have a test harness of your development?

No I do not.  Usually I test against asterisk.

> 3. i don't have much experience with multi-threading. can you tell me 
> what the major (possibly also open) issues were/are?

I actually wanted to get rid of the threads.  See
http://tinyurl.com/49mpnt

> 4. is there a chance to obtain a normalized (machine-readable) scheme of 
> the API commands and their syntax on-the-fly by asking the Asterisk/a 
> website?

Hmm... from asterisk there is a ShowCommands manager action I think (or
something similar to that).  I don't know of any machine readable
listings online.  You also have to keep in mind that some manager
actions are provided by the main/manager.c file in the asterisk core,
but others are provided by modules, that may or may not be there
depending on the configuration of the system.

-- 
Matthew Nicholson
Digium