Hooks in Base Code

Brad Pitcher bradpitcher at gmail.com
Thu Jul 19 00:34:35 CEST 2007

sure we couldn't do it directly like that.  But couldn't we fake it by have
the phone answer the call immediately after it detects it, playing the sound
file over the radio (instead of sending microphone input), and act like it's
still ringing?

On 7/18/07, Daniel Robinson <dgrobinson at dgrobinson.com> wrote:
> I don't know how much of the at signaling is available at the data
> terminal.  What is the signaling for sending caller ID to a cellular phone?
> For example, on POTS, the digits are signaled with a Bell 103 modem between
> the first and second ring.
> Someone said something about having the ringback tone be a sound file that
> is configurable according to caller.  I don't know if that is possible from
> the phone.  The ring back tone is generated by switching equipment, not the
> terminal.
> --Dan
> On 7/18/07, Jim McDonald <Jim at devzero.net> wrote:
> >  [This may have been better to post to the development list but as
> > people are talking about it here I'll start here]
> >
> > Hi,
> >    A number of people have been talking about the cool things that they
> > would like their 'phone to do but after spending some time looking at the
> > information available so far I don't see anything that suggests the current
> > codebase will allow people the freedom that they need.  If I take a simple
> > example of an incoming call them some of the suggestions that we have seen
> > so far to handle it include different ring tones for different people or
> > groups of people, auto-handling of the call by sending it to voicemail or
> > letting it through, different responses depending on the time of day, *etc.
> > *The point that I'm trying to make is that there are a multitude of
> > things that you *could* do but each person will have a limited number of
> > things that they want the 'phone to *actually* do.  As such, building
> > out all of these options in to a single piece of code will not only be very
> > hard to manage and maintain but will severely limit the ability of people to
> > scratch their itches and develop code to make the 'phone do what they want
> > it to.
> >
> >    If the monolithic approach is out then some sort of modular approach
> > is required.  The most obvious example out there today is Firefox, which
> > comes in a relatively simple base configuration but provides any number of
> > hooks to allow people to write their own extensions on top of the base code
> > and as such to alter the functionality of the product very extensively.  If
> > we want this openmoko to be as free as possible then it also needs to be as
> > easy as possible for people to extend, and this is the most likely way of
> > doing it.
> >
> >    I know that there are a lot of potential problems that need to be
> > addressed when building this out but if there is a vision from the start as
> > to how this would work then it would go a long way to making the final
> > product the 'phone that we are all dreaming of, regardless of the fact that
> > those dreams are often divergent from others if not totally exclusive.  So
> > my questions are there plans to include these hooks, and if not can it be
> > considered?
> >
> >    Or is there another way to do this other than hooks?
> >
> > Cheers,
> > Jim.
> >
> > _______________________________________________
> > OpenMoko community mailing list
> > community at lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/community
> >
> >
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20070718/819cc817/attachment.htm 

More information about the community mailing list