Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Feedback on the SMS API
77 views
Skip to first unread message
David Bruant
Nov 6, 2012, 7:32:00 AM11/6/12
to dev-w...@lists.mozilla.org
Hi,
My comments are based on the wiki.mo page [1].
# First, why does every operation return a SmsRequest? For instance, the
getMessage method could return the result directly, no?
# 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?
# The send method takes a string as first argument. String rarely are a
good thing to represent objects. Especially phone numbers.
An anecdote, In France, cell phone numbers used to start with "06". We
ran out, so it's been decided that cell phone numbers would also start
with "07". A friend of mine shared with me that it took 6 months of
development to FranceTelecom (historical and major Telco operator) to
prepare to this change, mostly because they used strings to represent
phone numbers.
Especially with cell phones shipping all across the globe, I really
think there is value in having an object representation of phone
numbers, very much like we do (sort of) with URLs.
# 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.
# What is "getNumberOfMessagesForText" for?
# "Should use opaque objects as message-identifiers rather than longs?"
=> Yes, and the SmsMessage instance itself is this object.
From the object capability perspective, it would be better to be able
to delete only messages you have access to.
Actually, I would rather prefer SmsMessage.prototype.delete than
SmsManager.delete, this way, it's clear you can only delete messages you
have access to.
# getMessages and SmsFilter
A more generic way would be to accept a function as first argument. This
function is passed a SmsMessage and returns true or false depending on
whether we want to keep the message or not akin to Array.prototype.filter.
It would be interesting to provide some convenience with SmsFilters:
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.
I think that's it for now :-)
David
[1] https://wiki.mozilla.org/WebAPI/WebSMS
My comments are based on the wiki.mo page [1].
# First, why does every operation return a SmsRequest? For instance, the
getMessage method could return the result directly, no?
# 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?
# The send method takes a string as first argument. String rarely are a
good thing to represent objects. Especially phone numbers.
An anecdote, In France, cell phone numbers used to start with "06". We
ran out, so it's been decided that cell phone numbers would also start
with "07". A friend of mine shared with me that it took 6 months of
development to FranceTelecom (historical and major Telco operator) to
prepare to this change, mostly because they used strings to represent
phone numbers.
Especially with cell phones shipping all across the globe, I really
think there is value in having an object representation of phone
numbers, very much like we do (sort of) with URLs.
# 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.
# What is "getNumberOfMessagesForText" for?
# "Should use opaque objects as message-identifiers rather than longs?"
=> Yes, and the SmsMessage instance itself is this object.
From the object capability perspective, it would be better to be able
to delete only messages you have access to.
Actually, I would rather prefer SmsMessage.prototype.delete than
SmsManager.delete, this way, it's clear you can only delete messages you
have access to.
# getMessages and SmsFilter
A more generic way would be to accept a function as first argument. This
function is passed a SmsMessage and returns true or false depending on
whether we want to keep the message or not akin to Array.prototype.filter.
It would be interesting to provide some convenience with SmsFilters:
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.
I think that's it for now :-)
David
[1] https://wiki.mozilla.org/WebAPI/WebSMS
JOSE MANUEL CANTERA FONSECA
Nov 6, 2012, 9:15:03 AM11/6/12
to David Bruant, dev-w...@lists.mozilla.org
El 06/11/12 13:32, "David Bruant" <brua...@gmail.com> escribió:
>Hi,
>
>My comments are based on the wiki.mo page [1].
>
># First, why does every operation return a SmsRequest? For instance, the
>getMessage method could return the result directly, no?
>
># 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?
It is used in all FFOS APIs including indexedDB. I'm sympathetic to what
you are saying but it would trivial to create a library that uses promises
to achieve the same effect.
>
># The send method takes a string as first argument. String rarely are a
>good thing to represent objects. Especially phone numbers.
>An anecdote, In France, cell phone numbers used to start with "06". We
>ran out, so it's been decided that cell phone numbers would also start
>with "07". A friend of mine shared with me that it took 6 months of
>development to FranceTelecom (historical and major Telco operator) to
>prepare to this change, mostly because they used strings to represent
>phone numbers.
>Especially with cell phones shipping all across the globe, I really
>think there is value in having an object representation of phone
>numbers, very much like we do (sort of) with URLs.
>
># 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) });
In that case you are making more calls to the API and on the other hand
you are losing semantics i.e it is not the same to send a message to a set
of recipients than sending a message to different recipients but what
happens is that actually the content of the message is the same. Last but
not least I think it may have implications in terms of delivery reports
and that kind of staff.
>
>It would probably simplify the implementation of send on your side.
>
># What is "getNumberOfMessagesForText" for?
>
># "Should use opaque objects as message-identifiers rather than longs?"
>=> Yes, and the SmsMessage instance itself is this object.
> From the object capability perspective, it would be better to be able
>to delete only messages you have access to.
>Actually, I would rather prefer SmsMessage.prototype.delete than
>SmsManager.delete, this way, it's clear you can only delete messages you
>have access to.
The API implementation has access to all messages provided the permission
was granted AFAIK
>
># getMessages and SmsFilter
>A more generic way would be to accept a function as first argument. This
>function is passed a SmsMessage and returns true or false depending on
>whether we want to keep the message or not akin to Array.prototype.filter.
>It would be interesting to provide some convenience with SmsFilters:
>
> 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.
>
>I think that's it for now :-)
>
>David
>
>[1] https://wiki.mozilla.org/WebAPI/WebSMS
>_______________________________________________
>dev-webapi mailing list
>dev-w...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-webapi
>
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>Hi,
>
>My comments are based on the wiki.mo page [1].
>
># First, why does every operation return a SmsRequest? For instance, the
>getMessage method could return the result directly, no?
>
># 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?
you are saying but it would trivial to create a library that uses promises
to achieve the same effect.
>
># The send method takes a string as first argument. String rarely are a
>good thing to represent objects. Especially phone numbers.
>An anecdote, In France, cell phone numbers used to start with "06". We
>ran out, so it's been decided that cell phone numbers would also start
>with "07". A friend of mine shared with me that it took 6 months of
>development to FranceTelecom (historical and major Telco operator) to
>prepare to this change, mostly because they used strings to represent
>phone numbers.
>Especially with cell phones shipping all across the globe, I really
>think there is value in having an object representation of phone
>numbers, very much like we do (sort of) with URLs.
>
># 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) });
you are losing semantics i.e it is not the same to send a message to a set
of recipients than sending a message to different recipients but what
happens is that actually the content of the message is the same. Last but
not least I think it may have implications in terms of delivery reports
and that kind of staff.
>
>It would probably simplify the implementation of send on your side.
>
># What is "getNumberOfMessagesForText" for?
>
># "Should use opaque objects as message-identifiers rather than longs?"
>=> Yes, and the SmsMessage instance itself is this object.
> From the object capability perspective, it would be better to be able
>to delete only messages you have access to.
>Actually, I would rather prefer SmsMessage.prototype.delete than
>SmsManager.delete, this way, it's clear you can only delete messages you
>have access to.
was granted AFAIK
>
># getMessages and SmsFilter
>A more generic way would be to accept a function as first argument. This
>function is passed a SmsMessage and returns true or false depending on
>whether we want to keep the message or not akin to Array.prototype.filter.
>It would be interesting to provide some convenience with SmsFilters:
>
> 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.
>
>I think that's it for now :-)
>
>David
>
>[1] https://wiki.mozilla.org/WebAPI/WebSMS
>dev-webapi mailing list
>dev-w...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-webapi
>
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
David Bruant
Nov 6, 2012, 9:40:05 AM11/6/12
to JOSE MANUEL CANTERA FONSECA, dev-w...@lists.mozilla.org
Le 06/11/2012 15:15, JOSE MANUEL CANTERA FONSECA a écrit :
> El 06/11/12 13:32, "David Bruant" <brua...@gmail.com> escribió:
>
>> Hi,
>>
>> My comments are based on the wiki.mo page [1].
>>
>> # First, why does every operation return a SmsRequest? For instance, the
>> getMessage method could return the result directly, no?
>>
>> # 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?
> It is used in all FFOS APIs including indexedDB.
SmsRequest is used in IndexedDB? and all FFOS APIs?
> El 06/11/12 13:32, "David Bruant" <brua...@gmail.com> escribió:
>
>> Hi,
>>
>> My comments are based on the wiki.mo page [1].
>>
>> # First, why does every operation return a SmsRequest? For instance, the
>> getMessage method could return the result directly, no?
>>
>> # 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?
> It is used in all FFOS APIs including indexedDB.
> I'm sympathetic to what
> you are saying but it would trivial to create a library that uses promises
> to achieve the same effect.
>> # The send method takes a string as first argument. String rarely are a
>> good thing to represent objects. Especially phone numbers.
>> An anecdote, In France, cell phone numbers used to start with "06". We
>> ran out, so it's been decided that cell phone numbers would also start
>> with "07". A friend of mine shared with me that it took 6 months of
>> development to FranceTelecom (historical and major Telco operator) to
>> prepare to this change, mostly because they used strings to represent
>> phone numbers.
>> Especially with cell phones shipping all across the globe, I really
>> think there is value in having an object representation of phone
>> numbers, very much like we do (sort of) with URLs.
>>
>> # 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) });
> In that case you are making more calls to the API and on the other hand
> you are losing semantics i.e it is not the same to send a message to a set
> of recipients than sending a message to different recipients but what
> happens is that actually the content of the message is the same. Last but
> not least I think it may have implications in terms of delivery reports
> and that kind of staff.
recipients rather than just one as the API exposes? It's unfortunate to
offer the semantics on send, but not being able to recover it when
introspecting messages :-)
>> It would probably simplify the implementation of send on your side.
>>
>> # What is "getNumberOfMessagesForText" for?
>>
>> # "Should use opaque objects as message-identifiers rather than longs?"
>> => Yes, and the SmsMessage instance itself is this object.
>> From the object capability perspective, it would be better to be able
>> to delete only messages you have access to.
>> Actually, I would rather prefer SmsMessage.prototype.delete than
>> SmsManager.delete, this way, it's clear you can only delete messages you
>> have access to.
> The API implementation has access to all messages provided the permission
> was granted AFAIK
rather than the SmsManager?
David
Jonas Sicking
Nov 9, 2012, 4:03:44 AM11/9/12
to David Bruant, dev-webapi
On Tue, Nov 6, 2012 at 4:32 AM, David Bruant <brua...@gmail.com> wrote:
> Hi,
>
> My comments are based on the wiki.mo page [1].
>
> # First, why does every operation return a SmsRequest? For instance, the
> getMessage method could return the result directly, no?
They return SmsRequest because they need to be asynchronous. Getting a
> Hi,
>
> My comments are based on the wiki.mo page [1].
>
> # First, why does every operation return a SmsRequest? For instance, the
> getMessage method could return the result directly, no?
message requires IO and all IO has to be async.
> # 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?
someone gets something standardized then I'd love to switch to using
it.
https://twitter.com/SickingJ/status/202152629743255552
> # The send method takes a string as first argument. String rarely are a good
> thing to represent objects. Especially phone numbers.
> An anecdote, In France, cell phone numbers used to start with "06". We ran
> out, so it's been decided that cell phone numbers would also start with
> "07". A friend of mine shared with me that it took 6 months of development
> to FranceTelecom (historical and major Telco operator) to prepare to this
> change, mostly because they used strings to represent phone numbers.
> Especially with cell phones shipping all across the globe, I really think
> there is value in having an object representation of phone numbers, very
> much like we do (sort of) with URLs.
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.
> # What is "getNumberOfMessagesForText" for?
write a longer message which under the hood is recoded and sent as
multiple messages which are then puzzled back together on the receiver
side. However the user still pays for each 160 character message. This
function allows calculating how many messages a piece of text would
get recoded into which enables displaying UI to the user so that the
user will know the cost of sending a given piece of text.
> # "Should use opaque objects as message-identifiers rather than longs?"
> => Yes, and the SmsMessage instance itself is this object.
> From the object capability perspective, it would be better to be able to
> delete only messages you have access to.
> Actually, I would rather prefer SmsMessage.prototype.delete than
> SmsManager.delete, this way, it's clear you can only delete messages you
> have access to.
IndexedDB, which can be quite useful when building more complex UIs.
> # getMessages and SmsFilter
> A more generic way would be to accept a function as first argument. This
> function is passed a SmsMessage and returns true or false depending on
> whether we want to keep the message or not akin to Array.prototype.filter.
> It would be interesting to provide some convenience with SmsFilters:
>
> 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.
index to iterate just the messages that are requested.
/ Jonas
David Bruant
Nov 9, 2012, 4:58:35 AM11/9/12
to Jonas Sicking, dev-webapi
Le 09/11/2012 09:03, Jonas Sicking a écrit :
> On Tue, Nov 6, 2012 at 4:32 AM, David Bruant <brua...@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
> On Tue, Nov 6, 2012 at 4:32 AM, David Bruant <brua...@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
>> # The send method takes a string as first argument. String rarely are a good
>> thing to represent objects. Especially phone numbers.
>> An anecdote, In France, cell phone numbers used to start with "06". We ran
>> out, so it's been decided that cell phone numbers would also start with
>> "07". A friend of mine shared with me that it took 6 months of development
>> to FranceTelecom (historical and major Telco operator) to prepare to this
>> change, mostly because they used strings to represent phone numbers.
>> Especially with cell phones shipping all across the globe, I really think
>> there is value in having an object representation of phone numbers, very
>> much like we do (sort of) with URLs.
> 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.
several people, it's not the same than sending two messages with the
same content to two different people.
Assuming this semantics was kept in the SmsMessage object (it isn't
currently since a given message can only have one receiver), I agree it
would make sense to keep the array as argument.
>> # What is "getNumberOfMessagesForText" for?
> SMS messages are limited to 160 characters. However you can still
> write a longer message which under the hood is recoded and sent as
> multiple messages which are then puzzled back together on the receiver
> side. However the user still pays for each 160 character message. This
> function allows calculating how many messages a piece of text would
> get recoded into which enables displaying UI to the user so that the
> user will know the cost of sending a given piece of text.
>> # "Should use opaque objects as message-identifiers rather than longs?"
>> => Yes, and the SmsMessage instance itself is this object.
>> From the object capability perspective, it would be better to be able to
>> delete only messages you have access to.
>> Actually, I would rather prefer SmsMessage.prototype.delete than
>> SmsManager.delete, this way, it's clear you can only delete messages you
>> have access to.
> This would make it impossible to store a message identifier in
> IndexedDB, which can be quite useful when building more complex UIs.
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.
>> # getMessages and SmsFilter
>> A more generic way would be to accept a function as first argument. This
>> function is passed a SmsMessage and returns true or false depending on
>> whether we want to keep the message or not akin to Array.prototype.filter.
>> It would be interesting to provide some convenience with SmsFilters:
>>
>> 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.
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).
Also, I forgot, but in the getMessages method, both arguments should be
optional in my opinion. Reverse defaulting to false and filter to...
undefined? and no filter would return a promise (hopefully soon) to all
messages.
David
Jonas Sicking
Nov 12, 2012, 7:18:31 PM11/12/12
to David Bruant, dev-webapi
On Fri, Nov 9, 2012 at 1:58 AM, David Bruant <brua...@gmail.com> wrote:
> Le 09/11/2012 09:03, Jonas Sicking a écrit :
>>
>> On Tue, Nov 6, 2012 at 4:32 AM, David Bruant <brua...@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
I'm quite serious. The web needs a standardized promise.
> Le 09/11/2012 09:03, Jonas Sicking a écrit :
>>
>> On Tue, Nov 6, 2012 at 4:32 AM, David Bruant <brua...@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
message to multiple people. When you are entering multiple recipients
in an SMS app it actually turns around and sends a set of separate
messages. This is why this function returns an array of SMSRequests,
since the messages will be sent independently and thus can fail
independently.
MMS however allows sending a single message to multiple people. But
the API doesn't support MMS yet. And I don't think the API should get
into the business of trying to guess when to send a message as an SMS
and when to send it as an MMS.
>>> # "Should use opaque objects as message-identifiers rather than longs?"
>>> => Yes, and the SmsMessage instance itself is this object.
>>> From the object capability perspective, it would be better to be able to
>>> delete only messages you have access to.
>>> Actually, I would rather prefer SmsMessage.prototype.delete than
>>> SmsManager.delete, this way, it's clear you can only delete messages you
>>> have access to.
>>
>> 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.
my opinion. Otherwise it gets very hard to cache any data locally in
the app and cross-reference to the SMS database.
messages that you have exchanged with a specific person, vs. using a
filter which is required to scan the 10000 messages that you have in
the full database is about three orders of magnitude :)
So yes, it makes a big difference.
We recently had to rewrite a part of the SMS app in order to avoid a
full database scan since it caused the app to take several seconds to
start. With the rewrite the database scan is basically instantaneous.
> Also, I forgot, but in the getMessages method, both arguments should be
> optional in my opinion. Reverse defaulting to false and filter to...
> undefined? and no filter would return a promise (hopefully soon) to all
> messages.
/ Jonas
David Bruant
Nov 13, 2012, 4:11:28 PM11/13/12
to Jonas Sicking, dev-webapi
Le 13/11/2012 01:18, Jonas Sicking a écrit :
> On Fri, Nov 9, 2012 at 1:58 AM, David Bruant <brua...@gmail.com> wrote:
>> Le 09/11/2012 09:03, Jonas Sicking a écrit :
>>> 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
> I'm quite serious.
I know and that's what makes me happy.
> On Fri, Nov 9, 2012 at 1:58 AM, David Bruant <brua...@gmail.com> wrote:
>> Le 09/11/2012 09:03, Jonas Sicking a écrit :
>>> 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
> I'm quite serious.
> The web needs a standardized promise.
I suggested in my original message?
> MMS however allows sending a single message to multiple people. But
> the API doesn't support MMS yet. And I don't think the API should get
> into the business of trying to guess when to send a message as an SMS
> and when to send it as an MMS.
MMS. Is it outdated, then?
>>>> # "Should use opaque objects as message-iden
>>>> tifiers rather than longs?"
>>>> => Yes, and the SmsMessage instance itself is this object.
>>>> From the object capability perspective, it would be better to be able to
>>>> delete only messages you have access to.
>>>> Actually, I would rather prefer SmsMessage.prototype.delete than
>>>> SmsManager.delete, this way, it's clear you can only delete messages you
>>>> have access to.
>>> 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.
> Being able to store identifiers in local databases is a requirement in
> my opinion. Otherwise it gets very hard to cache any data locally in
> the app and cross-reference to the SMS database.
I think we agree; I wrote "I agree message ids should be kept in the
>>>> => Yes, and the SmsMessage instance itself is this object.
>>>> From the object capability perspective, it would be better to be able to
>>>> delete only messages you have access to.
>>>> Actually, I would rather prefer SmsMessage.prototype.delete than
>>>> SmsManager.delete, this way, it's clear you can only delete messages you
>>>> have access to.
>>> 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.
> Being able to store identifiers in local databases is a requirement in
> my opinion. Otherwise it gets very hard to cache any data locally in
> the app and cross-reference to the SMS database.
SmsMessage API and as a retrieval mechanism in SmsManager.get(id)"
To be more concrete, the way I see the APIs, we would have (I'm making
all relevant changes):
interface SmsManager
{
DOMRequest send(DOMString number, DOMString message);
unsigned short getNumberOfMessagesForText(in DOMString text);
DOMRequest getMessage(in long id); //
request.result == SMSMessage
DOMRequest getMessages(in SMSFilter filter, bool reverse); //
request.result == SMSIterator
};
interface SmsMessage
{
readonly attribute long id;
readonly attribute DOMString delivery; // could be "sent" or "received"
readonly attribute DOMString sender;
readonly attribute DOMString receiver;
readonly attribute DOMString body;
readonly attribute Date timestamp;
attribute boolean read;
DOMRequest delete();
};
/** CHANGES
* I used DOMRequest instead of the SMS-specific SMSRequest
* I got rid of id-based method except .getMessage
* I got rid of send for an array since it's not relevant for SMS and
devs can do the same in one line of JS.
* SmsManager.markMessageRead is gone and SmsMessage.read is RW (the
ECMAScript representation is a getter/setter that does the right
coercion according to WebIDL)
* delete is on the SmsMessage interface (where it belongs in my opinion)
*/
still allows to do what the current API allows (including leveraging
indexes!). I just provide more flexibility if people want to create
custom filters. But it's really the same thing.
I've already done half of it, but after your reply to this message, I'll
propose a new IDL and upon agreement, I'll file a bug to modify the API.
David
[1] https://wiki.mozilla.org/WebAPI/WebSMS
Vicamo Yang
Nov 14, 2012, 8:39:59 AM11/14/12
to mozilla.d...@googlegroups.com, dev-webapi
On Wednesday, November 14, 2012 5:11:37 AM UTC+8, David Bruant wrote:
> /** CHANGES
>
> * I used DOMRequest instead of the SMS-specific SMSRequest
There is already a bug 749086 for this.
> /** CHANGES
>
> * I used DOMRequest instead of the SMS-specific SMSRequest
https://bugzilla.mozilla.org/show_bug.cgi?id=749086
> * I got rid of id-based method except .getMessage
> * I got rid of send for an array since it's not relevant for SMS and
> devs can do the same in one line of JS.
let msg = new MmsMessage();
// Populate required fields like subject, TO/CC/BCC, attachments, ...
MmsManager.send(msg);
We can also use this interface for SMS because some features like sending messages with additional Reply-Path, Message-Class information is still not supported in current SMS implementation. So we can have:
let msg = new Message(); // However, this name is already used internally.
// Sets required attributes, e.g. body for SMS, smilDocument for MMS
MessageManager.send(msg);
Vicamo Yang
Nov 14, 2012, 8:39:59 AM11/14/12
to mozilla-d...@lists.mozilla.org, dev-webapi
On Wednesday, November 14, 2012 5:11:37 AM UTC+8, David Bruant wrote:
> /** CHANGES
>
> * I used DOMRequest instead of the SMS-specific SMSRequest
>
> * I used DOMRequest instead of the SMS-specific SMSRequest
> * I got rid of id-based method except .getMessage
> * I got rid of send for an array since it's not relevant for SMS and
> devs can do the same in one line of JS.
> * I got rid of send for an array since it's not relevant for SMS and
> devs can do the same in one line of JS.
0 new messages