RE: Issue 12: Gathering requirements [Gallery API]

Hi Robin,

This touches on some things we could consider for our umbrella
requirements document.

The need to access the file system could also likely to be required from
other APIs:

- Contacts API - e.g. setting or getting a contact's profile picture
- User Interaction API - e.g. setting or getting e.g. sound files such
as ringtones or wallpapers, etc
- Gallery API - e.g. moving, creating, removing gallery items around a
gallery file system.
- Application Launcher - e.g. specifying a particular program to execute
on the file system
- ...

[note: these are just informal examples as requirements are still TBD on
the whole for these APIs]

So it may be that access to file system resources may be a core
requirement across other APIs. 

We've seen this issue crop up in BONDI. I guess we would also be
interested in being consistent across our DAP APIs on the subject of
cross-module dependencies. Perhaps it is a good idea to put in place
some general guidelines for this specific problem (or mitigate the
problem in the first place).

I have a number of outstanding questions that may help us explore this
issue:

- Are DAP APIs required as a whole for every implementation or are they
independently optional?
<------ i.e. is it always possible to rely on a FS API always being
present if, e.g. the Gallery API, is present on a device?

- Can DAP APIs use objects and methods from other DAP APIs? That is to
say, are cross-module dependencies between DAP APIs allowed/manageable?

- In the case that an API requires cross-module dependencies, what is
the security and policy requirement for such an API? Is a web app/widget
implicitly authorised for both APIs (i.e. in the Gallery API case
below)? Are the required features/capabilities across the dependent APIs
grouped? Is the required access to the dependent API suitably sandboxed
to prevent malicious use of what is essentially unauthorised access to
the FS API from a web app/widget?


These are some of the questions that bring on a cold sweat :-) I would
be interested in the thoughts of others. Perhaps we could register this
as an issue to start things off?

Cheers,

Richard

 
> On Sep 30, 2009, at 10:51 , Robin Berjon wrote:
> 
> Hi,
> 
> On Sep 28, 2009, at 19:24 , Tran, Dzung D wrote:
> > Gallery API:
> > 	* Browse for content
> > 	* List items
> > 	* Type: photo, video, audio, ..etc?
> > 	* URI
> > 	* Resource info: resolution, type
> > 	* Protocol info
> > 	* Rating
> > 	* Author, artist, genre, album, etc
> > 	* List containers
> > 	* Rights
> > 	* Move, create, remove
> > 	* Search
> 
> 
> I think that the above raises the question of the 
> relationship with the FS API. A number of the items above are 
> actually metadata (media type, resolution, authorial 
> information, rights...). Are those available only through the 
> gallery or should they be available through the FS (when 
> present) as well?
> 
> On the one hand it's tempting to define the Gallery API as 
> just an access to well-known locations of the FS, on the 
> other hand I'm a bit scared at the idea of specifying an 
> ontology for file metadata (even if limited). Maybe we can 
> make it simple though.
> 
> Thoughts?
> 
> --
> Robin Berjon
>    robineko - setting new standards
>    http://robineko.com/
> 
> 
> 
> 
>

Received on Wednesday, 30 September 2009 10:25:56 UTC