Hi, The libgfapi-python (http://review.gluster.org/#/admin/projects/libgfapi-python) project has been under development for some time now. Before it's going to be widely used and integrated into OpenStack projects, we would like to ensure that the consumer APIs are user-friendly, intuitive and "Pythonic".
The idea was to make the libgfapi-python APIs mimic the ones provided by following Python modules so that programmers find it easy to adapt and use: * os module (https://docs.python.org/2/library/os.html) * Built-in File object (https://docs.python.org/2/library/stdtypes.html#file-objects) * shutil (https://docs.python.org/2/library/shutil.html) Here's the API matrix which states the current status of APIs: https://www.ethercalc.org/0psqmoqm8r The File class (https://github.com/gluster/libgfapi-python/blob/master/gluster/gfapi.py#L19) as of today is a thin wrapper around the glfd object. But unlike the Python's built-in File object, there's no I/O buffering involved. Example workflow as of today (it's a mix of built-in File object and os module usage, which is easy to use but inconsistent): >>> import os >>> from gluster import gfapi >>> v = gfapi.Volume(host, volume, protocol, port) >>> v.mount() >>> f = v.open("path/to/file, os.O_WRONLY) >>> f.write("hello world") >>> f.close() We wan't to clearly demarcate the APIs that mimic built-in File object from the ones that mimic os module: Example 1 (more like os module): >>> glfd = v.open("path/to/file, os.O_RDONLY) >>> v.write(glfd, "hello world", 11) >>> v.close(glfd) Example 2 (like python's File object): >>> f = File("path/to/file, 'r') >>> f.write("hello world") >>> f.close() We would also want to do away with return values (like 0 or -1). The Pythonic way is: if something did not succeed, raise an exception (OSError or IOError). What do you guys think (as consumers) ? Regards, -Prashanth Pai _______________________________________________ Gluster-devel mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-devel
