Re: [Messaging API based on webinos]

[top posting to keep consistency]

Both opinions are founded. However, I think that during the
_development_ of the API's, even separate Messaging API's should be
specified in a single document (and eventually split only after
consolidation), for the following reasons:
- there is a lot of functionality which can be reused across all
messaging apps: support for service/accounts/multiple SIMs,  folders,
labels, search, storage access, asynchronous calls, iterating over
results, notifications!!!, etc. It is true these may be also
interesting to other API's than messaging.
- messages can be defined by extending, thus avoiding redundancy in
specification
- there are messaging middleware for common handling of all messages
(with one or separate storage, that is a different issue), and there
are ones which handle everything separately. Whereas it is possible to
have separated implementations for a unified spec, it is very
difficult to have a unified implementation of separate and diverging
specs which never went through alignment and consolidation from the
common use cases point of view. Therefore the better way to do it
would be either the unified API if feasible, or  separate but aligned
API's in a single spec - at least during the design phase of the
API's.

I tried to define the Intel spec so that there is one specification,
but separate namespaces for the different messaging types, so for app
developers looks and feels it is separate. For platform development
one can choose separate vertical stacks or integrated middleware.

Having one spec should not mandate implementing all of the messaging
types. As I said, we should seek consensus on cellular messaging first
(SMS, MMS and USSD). But during this discussion I would like that we
go through the use cases of IM (similar to SMS), email (similar to
MMS), and group chat (complex with contacts and presence, multiple
rooms, etc). In my experience even if we design separate API's, we
need to reflect to a all messaging use cases during the process, so we
don't build in problems which will be much  more difficult to solve
later. Moreover, there should not be style and consistency issues
across messaging API's either.

Since there are quite divergent opinions, development models and
targets, the best process would be an early face to face meeting,
within 2-3 weeks. Only after that I would put the question of separate
specs. If we start discussing these in email, may take multiple times
the time - it's not forbidden to try, though.

Until then, let's review shortly each Messaging proposal with pro's and con's:
- what use cases are solved
- if use cases (messaging types) are not covered, explanation is
needed on how the authors would solve the missing use cases
- is there anything wrong with the design
- usability and consistency of the API's
- feasibility
- forward compatibility with later development. A related topic is API
versioning. How an app would know the API version? Also, multiple
versions of the API may need to be supported (1-2 major releases
backward).

During this process it will be more clear which approach works better
within this group.

Best regards,
Zoltan


On Thu, Jan 3, 2013 at 5:42 PM, SULLIVAN, BRYAN L <bs3131@att.com> wrote:
> I agree with Jose. We have gone down this path a couple of times already (in
> BONDI and WAC, and DAP) and it was found that trying to have "one messaging
> API to rule them all" is tempting but ultimately too functionally warping to
> the needs of the individual messaging systems. Attachments and
> mailbox/folder management are examples of significantly divergent (or
> contextually irrelevant) functions.
>
> DAP ended up punting the whole API effort to the existing URI schemes. For
> SMS, that seems to work well (at least if you assume the user has to approve
> sending the message through the default messaging client, ie you forget
> automated sending) but it fails miserably for anything else.
>
> Thanks,
> Bryan Sullivan
>
> On Jan 3, 2013, at 7:28 AM, "JOSE MANUEL CANTERA FONSECA" <jmcf@tid.es>
> wrote:
>
> Hi there,
>
> Along the lines of these discussions I was wondering if it really makes
> sense to have a unique (one to rule them all) API for messaging or to have
> different APIs for different messaging protocols and technologies. The more
> I think on the issue the more I'm convinced that it is a better idea to have
> separate specs. The reasons for doing so are:
>
> A/ It is easier to get Conformance and to test implementation
> interoperability
> B/ It is easier to get consensus from the Community and to have the domain
> experts focused on the specific API
> C/ It is easier both for developers and for implementors
> D/ There are many differences between the different technologies and
> protocols that cannot be addressed in a single API that could make sense
>
> So IMHO the group should be focusing initially on the most simple which is
> text messaging and later think on other more complicated stuff
>
> Thanks, best
>
> De: Jonas Sicking <jonas@sicking.cc>
> Fecha: Mon, 31 Dec 2012 15:45:05 -0800
> Para: "Nilsson, Claes1" <Claes1.Nilsson@sonymobile.com>
> CC: "public-sysapps@w3.org" <public-sysapps@w3.org>,
> "webinos-wp8-ml@fokus.fraunhofer.de" <webinos-wp8-ml@fokus.fraunhofer.de>,
> Christian Fuhrhop <christian.fuhrhop@fokus.fraunhofer.de>, Vercelli Stefano
> <stefano.vercelli@telecomitalia.it>
> Asunto: Re: [Messaging API based on webinos]
> Nuevo envío de: <public-sysapps@w3.org>
> Fecha de nuevo envío: Mon, 31 Dec 2012 23:46:04 +0000
>
> With both this proposal, and the proposal from Intel, I'm wondering what
> type of applications is the target.
>
> As far as I can see, the email support in this API isn't enough to build for
> example a full-fledged email application. For that, you need IMAP support
> which means ability to enumerate the folder hierarchy and to query metadata
> about folders. You also need things like control over downloading
> attachments.
>
> You likely also need integration with server-side synchronization such as
> ActiveSync. I don't know exactly what this entails, but at least I would
> imagine it requires ability to query server-side metadata similar to IMAP.
>
> I also notice that there is no account configuration support in this API.
> This could be completely fine since that can be handled in a settings
> application on the device, separate from the email application. However I
> was wondering if this is something that you guys had looked into? It also
> seems like there needs to be some minimal amount of account management in an
> email API since you need to be able to enumerate which accounts are
> configured and be able to create UI which allows the user to choose which
> account to send an email with and which account to query when doing
> searching.
>
> I think a lot of the same questions apply to the IM. I.e. what are the
> target applications for this API. It doesn't seem like there is enough there
> to build a chat client that integrates with for example gtalk, irc, jabber
> or facebook messaging as backends.
>
> / Jonas
>
>
> On Mon, Dec 24, 2012 at 2:45 AM, Nilsson, Claes1
> <Claes1.Nilsson@sonymobile.com> wrote:
>>
>> Hi,
>>
>>
>>
>> I have submitted an example of a Messaging API,
>> http://sysapps.github.com/sysapps//proposals/Messaging_webinos/Messaging.HTML,
>> that supports SMS, MMS, E-mail and IM based on the current Webinos Messaging
>> API, which originally was based on the WAC Messaging API.
>>
>>
>>
>> This API has been implemented for SMS in the Android Webinos platform.
>>
>>
>>
>> Notes:
>>
>> ·        There has been a discussion, starting here
>> http://lists.w3.org/Archives/Public/public-sysapps/2012Oct/0040.html,  on
>> whether SysApps  only should specify an SMS/MMS API and leave support for
>> the other messaging technologies to JS libraries that use the Raw Socket
>> API. I am not taking a specific position here. The purpose with this
>> submission is to give an example of an API that directly provides high level
>> support for several Messaging technologies. This example can be beneficial
>> in further discussions on the approach on whether E-mail/IM should be
>> supported directly by a standardized API or by JS libraries that leverage
>> the Raw Socket API.
>>
>> ·        There has also been a discussion about filtering. The webinos
>> proposal contains a MessageFilter dictionary that defines specific filtering
>> attributes. However, a general approach to data models and filtering has
>> been proposed, starting at
>> http://lists.w3.org/Archives/Public/public-sysapps/2012Nov/0022.html, and we
>> should probably follow such an approach for Messaging as well.
>>
>> ·        In this proposal traditional callback function references is used
>> in method definitions, which differs from the style in other API proposals
>> submitted to SysApps. They use a return type that is an interface that
>> represents an ongoing operation. There is no specific reason for this
>> difference in the Webinos Messaging API. If the WG decides to base the
>> Messaging API on the Webinos example then style could be adapted to the
>> style of the other SysApps APIs.
>>
>> ·        We have included a cancel() method allowing applications cancel
>> an ongoing sendMessage or findMessage operation. This might be controversial
>> and this kind of method is generally not included in W3C APIs and
>> implementability is probably an issue. One exception is the File reader API,
>> which allows read operations to be aborted. So there are situations where an
>> ongoing asynchronous operation may need have to be aborted. Need to be
>> discussed.
>>
>>
>>
>> Best regards
>>
>>   Claes
>>
>> <image001.gif>
>>
>>
>>
>> Claes Nilsson M.Sc.E.E
>> Master Engineer, Research
>> Technology Research - Advanced Application Lab
>>
>> Sony Mobile Communications
>>  Phone:  +46 10 80 15178
>> Mobile: +46 705 56 68 78
>> Switchboard: +46 10 80 00000
>> E-Mail: mailto:claes1.nilsson@sonymobile.com
>> Visiting Address; Nya Vattentornet
>> SE-221 88 LUND,
>> Sweden
>>
>> Disclaimer:
>> The information in this e-mail is confidential and may be legally
>> privileged. It is intended solely for the named recipient(s) and access to
>> this e-mail by anyone else is unauthorized. The views are those of the
>> sender and not necessarily the views of Sony Ericsson and Sony Ericsson
>> accepts no responsibility or liability whatsoever or howsoever arising in
>> connection with this e-mail.Any attachment(s) to this message has been
>> checked for viruses, but please rely on your own virus checker and
>> procedures. If you contact us by e-mail, we will store your name and address
>> to facilitate communications. If you are not the intended recipient, please
>> inform the sender by replying this transmission and delete the e-mail and
>> any copies of it without disclosing it.
>>
>>
>
>
>
> ________________________________
>
> 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
>
> ---------------------------------------------------------------------
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki
> Business Identity Code: 0357606 - 4
> Domiciled in Helsinki
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.

Received on Thursday, 3 January 2013 17:26:02 UTC