>> On Tue, Nov 6, 2012 at 4:32 AM, David Bruant <bruan...@gmail.com> wrote:

>>> # The SmsRequest object smells like a promise. It does very very badly.
>>> What
>>> about actually making it a promise so it can share a uniform interface
>>> with
>>> other async features and things like Q.all (creates a promise that is
>>> fulfilled when all promises passed as arguments are fulfilled) be built
>>> on
>>> top of these promises?

>> I'd love to have a standardized promise API which we could use. If
>> someone gets something standardized then I'd love to switch to using
>> it.

>> https://twitter.com/SickingJ/status/202152629743255552

> :-D

>> So far no-one has come up with a standard for a parsed phone number.
>> We're still fighting over what a parsed URL looks like and phone
>> numbers are dramatically more complicated since the rules are
>> different in different countries.

>> If you figure out a way to solve this, I'm all ears.

>>> # I hardly see the need of the second send method that accepts an array.
>>> For
>>> a developer, it takes one longer line to achieve the same thing:
>>>      var requests = myNumbers.map(function(num){ return send(num,
>>> message)
>>> });

>>> It would probably simplify the implementation of send on your side.

>> I tend to agree.

> Jose's made a good point though, that when you send one message to several
> people, it's not the same than sending two messages with the same content to
> two different people.

>> This would make it impossible to store a message identifier in
>> IndexedDB, which can be quite useful when building more complex UIs.

> I agree message ids should be kept in the SmsMessage API and as a retrieval
> mechanism in SmsManager.get(id). But that's where it should stop in my
> opinion. Every operation that affects only a given message (delete,
> markAsRead) should be a method in the SmsMessage interface applied to the
> message instance, not in the SmsManager interface.

>>>       var filter = new SmsFilter({delivery: "received"});
>>>       SmsManager.getMessages(filter).then(function(receivedSms){
>>>           // ...
>>>       })
>>> (the "then" is assuming SmsRequest become promises)

>>> Basically, SmsFilter generates a function which [[Call]] does the right
>>> thing based on the passed arguments, but it's a convenience rather than a
>>> compulsory thing.

>> The performance of that would be really bad since we couldn't use an
>> index to iterate just the messages that are requested.

> How bad would it really be? What is the performance benefit (in time, not
> percentage) of having indexes? (If people have thousands of Sms, I hardly
> believe that an index makes a noticeable difference)
> Also, I agree that a user-generated function can't have the semantics to
> leverage indexes, but system generated functions using the SmsFilter
> constructor as I suggested could.
> What I've suggested allows to leverage anything that the current API offers.
> I'm just offering the freedom to do arbitrary filters (which the current API
> doesn't allow).