It was <2013-10-08 wto 18:12>, when Rusty Lynch wrote: > On Tue, 2013-10-08 at 14:59 +0200, Jacek Pielaszkiewicz wrote: >> Issues/topics that required future works: >> >> (1) Multi user support (open topic for TIZEN 3.0) >> >> (2) Which API should we exposed for TIZEN applications - native udisk API >> (dbus based) or build a new one on top of udisk API. > > Lets not create another abstraction layer. Native apps can just > directly call into the existing dbus API
I don't think application developers should be required to know about DBus. There should be "OSP binding for UDisks" (and every other DBus service). The binding layer should be thick enough to be stable if (when) UDisks API changes (It already has changed once). > and web apps do not have direct access to arbitrary storage. The way I understand web apps, they are meant to be no less potent than native ones. Nativity is rather for performance than "security". >> (4) Mount points location - by default udisks mount new block devices in >> /run/media/__user__/__device_name__ in TIZEN it is /opt/storage/sdcard - >> hardcoded. > > I think we should stop using the oddball location > under /opt/storage/sdcard and just fix whatever middleware is working > under this hard coded assumption. +1 >> (5) Integration udisks with TIZEN security (security-server, ...) > > Last I heard the security-server was marked for death, i.e. the overall > system was being addressed such that we should not need such a beast > anymore. But... I'll let the security folks comment on that. The security team I sit next to, might beg to differ ;-) -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics
pgpzLQ2lBReZe.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
