On Sun, Apr 13, 2008 at 11:57:58PM -0400, Benny Prijono wrote:
> > pjsua in such case look for settings in default file ("standard unix-like
> > naming/location convention" could be used, like f.e. ~/.pjsua).
> >
>
> Hmm, not sure. Can't find any good reason why not, but I kinda of like
> it this way (or maybe it's because I'm so used to it).
It can just spare some additional typing "--config-file=/directory/filename",
if the user wants to rely just on his defaults.
> Not sure about that. For me I prefer pjsua to be concise. Anything
> more intelligent should be done by a proper user interface.
> [..]
> > Pay attention, that some of the features - just like ring tone - could be
> > made at such additional user-interface level (f.e. "expect" detected "incoming
> > call from..." - so "play ringtone.wav" has been issued), allowing such way
> > an use of scripting languages to develop pjsua-based sip-phones. pjsua could
> > be kind of "core" for them.
> >
> >
> > What do you think?
>
> My general feeling is I think you'd probably be happier with creating
> another pjsua as your scripting core. And that's what Python is for.
Not sure, what you mean. Your tip for me is to write pjsua-clone entirely in
Python?
As you wrote above - and my personal feeling was similar - "more intelligent
[features] should be done by a proper user interface", therefore my idea was
to make communication of present pjsua client easier for the "higher level
UI", written in Python or any other scripting language. But not to write
another pjsua "from scratch" - and this time entirely in scripting language.
Yes, I noticed some "Python bindings" introduced - but pay attention, that
introducing messages (and commands) easier to recognize by tools like
"expect", you can make pjsua easier to cooperate with *any* scripting
language - be it Python, Perl, Rexx, TCL, Lua, Ruby or even bash script
using "expect" (similar way as "wvdial" works, although it's not bash
script). IMHO there's really no need to bind it tightly - using API - to any
specific language, if one can achieve the same result for *all* of them just
by standarizing application's messages and commands.
Have a look at expect ( http://expect.nist.gov/ ) - you'll surely see, what
I meant by that.
--
pozdrawiam / regards
Zbigniew Baniewski
