A few question...

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

 



On Mon, Apr 14, 2008 at 7:49 PM, Zbigniew Baniewski <zb at ispid.com.pl> wrote:
>  > 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.
>

Yes I know that. Like I said, I don't have a good reason to dislike
this. But for me personally, I have many config files that I will
chose according to which account I want to login to, and I don't have
a default config, so this wouldn't spare me the additional typing.

>  > 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?

Yes. It won't be that hard; we have a demo Python app that do many
things in 780 lines of code.

>  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.

Well that's my point. pjsua's output was never meant to be script
friendly as it tries to communicate with humans. And my proposal was
if you want anything like this, you can create a pjsua application in
Python, and then build your application (using any script you want) on
top of this Python application.

Right now I really don't have any idea on what you would expect the
pjsua output should be formatted. If you have a more concrete proposal
on how the output should be formatted I would gladly consider that.

>  Have a look at expect ( http://expect.nist.gov/ ) - you'll surely see, what
>  I meant by that.
>

I know expect, I used it many years ago.

Cheers
 Benny


> --
>                                 pozdrawiam / regards
>
>                                                 Zbigniew Baniewski
>
>  _______________________________________________
>  Visit our blog: http://blog.pjsip.org
>
>  pjsip mailing list
>  pjsip at lists.pjsip.org
>  http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>



[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux