It was <2013-10-16 śro 06:53>, when YOUNG IK CHO wrote: >> IOW, I think the specs Mikko referred to is quite good and should be >> used where possible. It is especially important to follow these to ease >> porting of Linux code and reduce number of bugs regarding upstream >> sources, because for example glib has functions to retrieve these XDG >> paths and those are used by a lot of open source software: >> g_get_user_cache_dir() >> g_get_user_data_dir() >> g_get_user_config_dir() >> g_get_user_runtime_dir() >> g_get_user_special_dir() >> g_get_system_data_dirs() >> g_get_system_config_dirs() > > Above APIs seems great if it meets following requirements: > > 1. Dependency > > If the application want to use above APIs, then it's fine. However, the > library > dependency matters for the library. As you stated, glib will be proper > baseline for > dependency tree. Maybe almost library does not have any issue with it.
In the worst case we can create our own lib that would provide this tiny part of Glib as a separate block. > 2. Scalability > > If we need to add other directory like media directory or app-root > directory, > app-data directory, we probably need to add more functions similar to above. > To handle > this situation, maybe we need to provide simple wrapper library and use above > glib > functions internally. I think extending the specification and Glib and pushing the changes upstream would be both possible and easier. -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics
pgpir0AQ46AD6.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
