[asterisk-users] SendImage()

[Tilghman Lesher]

On Saturday 22 November 2008 22:18:05 Rob Hillis wrote:
> Philipp Kempgen wrote:
> > SendImage() in 1.4:
> >
> > ---cut---
> >   SendImage(filename): Sends an image on a channel.
> > If the channel supports image transport but the image send
> > fails, the channel will be hung up. Otherwise, the dialplan
> > continues execution.
> > The option string may contain the following character:
> >     'j' -- jump to priority n+101 if the channel doesn't support image
> > transport This application sets the following channel variable upon
> > completion: SENDIMAGESTATUS        The status is the result of the
> > attempt as a text string, one of OK | NOSUPPORT
> > ---cut---
> >
> > in 1.6:
> >
> > ---cut---
> >   SendImage(filename): Sends an image on a channel.
> > Result of transmission will be stored in SENDIMAGESTATUS
> > channel variable:
> >     SUCCESS      Transmission succeeded
> >     FAILURE      Transmission failed
> >     UNSUPPORTED  Image transmission not supported by channel
> > ---cut---
> >
> > Is there any reason to break backwards compatibility?
> > Why is "SUCCESS" better than "OK" and "UNSUPPORTED" better than
> > "NOSUPPORT"?
> > IMHO there was no need to change anything except for adding
> > the "FAILURE" return status.

This is a case of "damned if you do, damned if you don't".  That is a
perfect complaint, and I understand it completely.  On the other side,
we are criticized for inconsistent behavior, inconsistent status names,
etc.  So we've chosen to make Asterisk more consistent going forward,
with the one-time problem of a slight change in behavior.  Current users
see an issue either way, and future users won't see a problem at all.

> Even the comments made at the time suggesting a parsing tool be provided
> to point out where changes to dialplan code would be required got a
> "nice idea" response, but nothing has been forthcoming.

As always, the problem is who is going to write such a tool.  The people who
are capable of writing such a tool are working on other things (like
getting CDRs to an acceptable place or extending bridging code to work
better, or lots of other things that will make Asterisk more useful in the
future), aren't yet involved in the Asterisk project, or are working on
something valuable for their own company.  Yes, I think we'd all like to see a
parser like that, but who has the time to write it?

> This habit of breaking functionality for limited or no reason, plus
> making the results from functions far /less/ useful (note my previous
> complaints about the REALTIME() function) and more difficult to use is
> the biggest problem with Asterisk bar none.

In 1.6.2, we will introduce REALTIME_FIELD and REALTIME_HASH to solve
the problems you've brought up before.  These functions are already in trunk,
and it shouldn't be too difficult to backport them to 1.4.

-- 
Tilghman