W3C home > Mailing lists > Public > public-sysapps@w3.org > November 2012

Re: Messaging - SMS API draft

From: Kis, Zoltan <zoltan.kis@intel.com>
Date: Thu, 15 Nov 2012 17:26:20 +0200
Message-ID: <CANrNqUeMC-+VbyXA4M4RgHAwz9+PWFXb-9e8ZTt0HF18i=x4dA@mail.gmail.com>
To: Mounir Lamouri <mounir@lamouri.fr>
Cc: public-sysapps@w3.org
On Thu, Nov 15, 2012 at 3:35 PM, Mounir Lamouri <mounir@lamouri.fr> wrote:
> On 26/10/12 12:14, Kis, Zoltan wrote:
>> SIP, XMPP, Skype, etc? How will that interwork with native stacks in
>> the same device? Port conflicts?
> I can have multiple email clients on my laptop and each of them have
> their own way to access my emails. I do not understand why it would be a
> problem here.

XMPP port conflict, for instance.

>> The way I see the web platform is a window to the native middleware.
>> You likely imagine it as a POSIX OS and write from scratch everything.
>> It should be possible to create products following either approach,
>> but we need API's that are good enough to cover both.
> I think we should only include in the Web Platform stuff that can't be
> done using Javascript nowadays.

OK, this is your use case.
But if you have a platform with both native and web API's, where most
functionality is done in middleware, and only exposed to JS, then do
you suggest using a different API?
Would that still be sysapp target?

This a fork point, so we need to resolve this.

I see easier to design the API's in a way to work with both setups.
Then, for the additional stuff what you plan to implement in JS, you
simply don't use the sysapp API's, and don't even implement them. I
still want to specify, implement and use API's e.g. for MMS, email,
and instant messaging. I guess others will want that too.
Saying that you want to fulfill only your own use case and everyone
else is on their own is pretty rude in an API standardization

Best regards,
Received on Thursday, 15 November 2012 15:26:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:10 UTC