Re: ISSUE-3 (async-style): Asynchrnonous calls style [APIs — General]

2009/9/1 Robin Berjon <robin@berjon.com>:
> On Aug 31, 2009, at 21:12 , Arve Bersvendsen wrote:
>> On Tue, 25 Aug 2009 15:08:36 +0200, Device APIs and Policy Working Group
>> Issue Tracker <sysbot+tracker@w3.org> wrote:
>>>
>>> ISSUE-3 (async-style): Asynchrnonous calls style [APIs — General]
>>>
>>> http://www.w3.org/2009/dap/track/issues/3
>>>
>>> Raised by: Robin Berjon
>>> On product: APIs — General
>>>
>>> We need to pick a common style for asynchronous calls (handles for
>>> cancellation, DOM Events or not, etc.).
>>
>> I'll ask the same question I did for ISSUE-2: Do we really? Whether
>> something is a callback or event, or is cancellable or not would depend on
>> the particular use-case, no?
>
> I'm fine with that if that's the general feeling of the WG, but at the very
> least rough guidelines about when to use events or callbacks could help. The
> WebApps WG recently tailspinned into several weeks of not-always-friendly
> discussion about events versus callbacks — I'd rather we avoided that.
>
> Here's a quick proposal, feel free to add to or subtract from it:
>
>  - Every asynchronous call should be cancellable, unless there are
> overriding technical issues that make the action irreversible (e.g.
> window.dropPiano()).

Imho there are quite a few irreversible or hard-to-reverse operations,
mostly long-running operations that change some data, like filesystem
manipulation (delete/copy/move) and DB manipulation
(contact/calendar/messaging/call).

Some of these operation are reversible to some extend -- like
file/contact creation, some of them are reversible on specific
platforms only (eg DB rollback/fs shadow copies), but most of these
reversions could be long running by themselves.

But there are also operations that can't  be reversed to a previous
state but should be still cancel-able. Like the recursive
copy/deletion of a directory. Such asynchronous operations might
happen by accident or be very long running that there should be a way
to cancel them "half way", risking an undefined state.

>  - Events will be used whenever there is a solid use case indicating
> decentralised observation or the need for simulating the action (synthetic
> events); otherwise callbacks will be used.

>From a calling perspective I'd say that callbacks tend to be called
once, whereas events are usually called indefinitely (= until an event
listener is explicitly removed). So callbacks should be used if one
expects a one-shot (or defined number of) notification(s), otherwise
events are used...

Kind regards,
Anselm

Received on Thursday, 10 September 2009 10:34:17 UTC