<div dir="ltr">Hello, thanks for your responses.<br><br>The swift interface will add an undesired extra interface to the data (plus probably the need of extra servers ?).<br>And we don&#39;t have the resource internally to take the time to better understand Gluster and create our custom client library/api.<br><br>We will ask the same question on the Ceph mailing list, and if there is the same difficulties, we probably abandon the idea of using Cluster/Ceph as part of our server infrastructure.</div><div class="gmail_extra"><br><div class="gmail_quote">2017-06-02 7:08 GMT+02:00 Niels de Vos <span dir="ltr">&lt;<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Jun 02, 2017 at 12:13:53AM -0400, Prashanth Pai wrote:<br>
&gt;<br>
&gt; ----- Original Message -----<br>
&gt; &gt; From: &quot;XoD&quot; &lt;<a href="mailto:xoddark@gmail.com">xoddark@gmail.com</a>&gt;<br>
&gt; &gt; To: <a href="mailto:gluster-devel@gluster.org">gluster-devel@gluster.org</a><br>
&gt; &gt; Sent: Thursday, 1 June, 2017 8:08:08 PM<br>
&gt; &gt; Subject: [Gluster-devel] Gluster API out of Unix environment<br>
&gt; &gt;<br>
&gt; &gt; Hello, in my company we are looking for a most efficient solution to<br>
&gt; &gt; distribute a lot of small files, for a lot of clients.<br>
&gt; &gt;<br>
&gt; &gt; We are considering using Glusterfs for this (Or Ceph) as our server<br>
&gt; &gt; infrastructure.<br>
&gt; &gt; On the client side we want to access data as object directly from the<br>
&gt; &gt; application.<br>
&gt; &gt; Our applications will not run in an Unix environment (Windows among others).<br>
&gt; &gt; But unfortunately the Gluster API (Or Ceph API) depends on Unix technologies<br>
&gt; &gt; and headers.<br>
&gt; &gt;<br>
&gt; &gt; So to summarize our needs for the API are :<br>
&gt; &gt; - put new files on a volume<br>
&gt; &gt; - read files on the volume<br>
&gt; &gt; - remove files on the volume<br>
&gt; &gt; We do not need to update any files after the first write.<br>
&gt; &gt;<br>
&gt; &gt; For the moment, here is our current investigation status:<br>
&gt; &gt; We have tried to build the api (libglusterfs) in a Msys/Mingw environment,<br>
&gt; &gt; but all dependencies are not available.<br>
&gt; &gt; We are considering to modify libglusterfs to replace Unix dependencies, but<br>
&gt; &gt; it&#39;s seems a lot of work.<br>
<br>
</div></div>The interface you would use in applications is in libgfapi.so. This<br>
library depends on libglusterfs and others. There is already support for<br>
Linux, NetBSD and partially (untested?) FreeBSD and Mac OSX. Adding<br>
support for an other UNIX-like implementation (Mingw, Cygwin, ..) should<br>
be doable, but might not be trivial.<br>
<span class=""><br>
&gt; &gt; We are considering to reimplement the client library, but I haven&#39;t found<br>
&gt; &gt; documentation about the communication protocol of libglusterfs api.<br>
&gt; &gt; We are also considering to create a new (simpler) API, possibly based on<br>
&gt; &gt; http, but we need to know how implement the server part.<br>
&gt;<br>
&gt;<br>
&gt; You can put and get files as objects using gluster-swift project. This happens<br>
&gt; over HTTP protocol with requests and responses conforming to Swift or S3 API.<br>
&gt; <a href="https://github.com/gluster/gluster-swift" rel="noreferrer" target="_blank">https://github.com/gluster/<wbr>gluster-swift</a><br>
<br>
</span>This is my suggestion as well. gluster-swift (with the Swift3 add-on) is<br>
an OS independent way of doing this.<br>
<span class=""><br>
&gt; &gt; Without any knowledge of the internal Gluster’s functionality it&#39;s not easy,<br>
&gt; &gt; and I haven&#39;t found any documentation about it.<br>
<br>
</span>The protocol is very sparsely documented, so writing a new<br>
implementation from scratch that will be difficult and a *lot* of work.<br>
Because Gluster is based on translators on both the client- and<br>
server-side, behaviour may change subtly depending on what features are<br>
enabled on the Gluster volume. Adding a new implementation will also<br>
require you to keep it updated whenever new functionalities are added to<br>
the protocol.<br>
<span class=""><br>
&gt; &gt; So here are my questions:<br>
&gt; &gt; Does anybody have advices/warnings about how we can achieve any of the afore<br>
&gt; &gt; mentioned ports ?<br>
&gt; &gt; Or know any open source library project to access to Gluster files/objects<br>
&gt; &gt; from (at least) a Windows application.<br>
<br>
</span>The best advise we can give is to abandon the idea of a Windows native<br>
Gluster implementation. Either use the (OpenStack) Swift, (Amazon) S3 or<br>
NFS/SMB protocols, the last two might have native Windows libraries too.<br>
<br>
Please keep us informed about your approach and plans, even if you<br>
decide to use something else as Gluster.<br>
<br>
Thanks and good luck!<br>
<span class="HOEnZb"><font color="#888888">Niels<br>
</font></span></blockquote></div><br></div>