I Wrote A Thin Python Wrapper Around The Bittorrent Sync Api

[sirphilip]

Hey guys,

 

I wrote a module that makes it easy to interface with the btsync API from python. Check it out

 

https://github.com/jminardi/python-btsync

 

Here is some sample code:

>>> # this code assumes a btsync instance is running>>> from btsync import BTSync>>> btsync = BTSync()>>> btsync.get_folders()[{u'dir': u'/Users/jack/sync/notes',  u'error': 0,  u'files': 13,  u'indexing': 0,  u'secret': u'NOPE',  u'size': 70867,  u'type': u'read_write'}]

I have only been wrapping the API calls as I need them, so not all have a nice method name. I should finish them soon, but for now you can just use the `request` method directly, like so:

 

`btsync.request({'method': 'get_folder_peers', 'secret': 'blah'})`

[tmac]

@sirphilip

 

I have been working on the same thing for almost 2 months now, but I did not have the time to put it on github. Now you can find my code here: https://github.com/tiagomacarios/pybtsync

 

It implements most of the documented API functions and has some other niceties too. For example if you dont have the btsync executable installed the script will download it and set everything.

 

I still have to document most of the code, but since it feels like you are interested in using python too, maybe we could work on it together?

 

Cheers,

tmac

 

 

[ctismer]

@sirphilip

@tmac

@tuxpoldo

 

Hi guys,

 

there are your implementations, and there is also since a while this on PyPi:

 

https://pypi.python.org/pypi/btsync.py/0.9.8

 

So the question is how and with whom to create a definitive btsync api wrapper?

 

https://github.com/jminardi/python-btsync

https://github.com/tiagomacarios/pybtsync/blob/master/pybtsync/pybtsync.py

https://github.com/kevinjqiu/btsync.py

https://github.com/tuxpoldo/btsync-deb/blob/master/btsync-gui/btsyncapi.py

 

I would like to merge all the efforts into the one, final implementation that is normatively

state of the art, supporting python 2.7 and 3.3/3.4

 

Can we please discuss this and come to some common concept?

 

Cheers - Chris

[tuxpoldo]

OK. Here a quick and dirty collection on my thoughts...
 
The first approach was published here and it is not in the list you wrote: https://github.com/BrandonIngalls/BTSyncAPI - it was definitively not complete (since it covered only a few methods) but it was the starting point for my implementation. I only modified it in order to work with the request library, support the strange charset conversion stuff, support both exceptions and return codes, etc. It is only a client library. Nothing more. And since it is really a very thin layer that may change often, I'm not sure, that it's now the time to provide a central library that has to be updated, maintained, distributed in various distributions, etc... This would only slow down the application development...

 

Please do not consider my thoughts as a quality judgement about your software! I am only telling, why I would not use it in my solution and this may perhaps be some criteria to take in consideration when creating a general available wrapper. I am sure, that you would find lots of things in my code why you would never use it in your application.

And now a fast look at the other libraries:
 
Jack Minardi: https://github.com/jminardi/python-btsync
 
I would not use it in my application since:

• It is still not complete. Only 5 methods
• Way to much imports: 7 libraries only to make a few HTTP requests? We should KIS (keep it simple...)
• Implements authentication by fiddling manually with headers...
• Scope unclean: contains a generator for a config file... A client library does not have to deal with managing the server process.... BTW: the checked in Source on GitHub contains a hardcoded API key. Not exactly what the terms and conditions require...
• def start(self): - this function is not only out of the scope of the API, it is also not really deterministic, since it does not handle all problems and implications of managing the process.

Tiago: https://github.com/tiagomacarios/pybtsync
 
I would not use it in my application since:

• Way to much imports: 11 libraries only to make a few HTTP requests? We should KIS (keep it simple...)
• Out of scope: def write_conf_file(...): Hey! It is a client API!!! It is not a server process manager!
• Out of scope: def download_btsync(self, btsync_dir): Wow! Not only it tries to manage a local btsync process, it wants also to download the executable from BitTorrent Inc!
• It mixes together too much stuff: Getting BitTorrent Sync (but only on Windows and Linux!), Creating a config file (but without really supporting any possible feature - further more this creates an additional version dependency...), some approach of process management (def start_process(...)) but without providing all functionality needed to really manage a local btsync process....

Kevin J. Qiu: https://github.com/kevinjqiu/btsync.py

 

This is a really interesting project. The most important aspect is:

 

It does not use the BitTorrent Sync API. It does instead rely on the Web Interface and uses the same access points used by the internal JS code of the Web UI.

 

Because of this it cannot be treated like the other projects. What I like is:

1. The project is very well structured (data model, classes, etc.)
2. It does not try to do things that have no relation with the task like managing the process...
3. It seems to be very compliant with a very canonical development process....

This approach unfortunately has also some disadvantages:

1. There is no guarantee that it will work, since it is using a very private, undocumented and internal interface that may be changed at any version...
2. I'm quite sure, that in future the official API will permit to make lots of more things....
3. Performance issues?

[tmac]

@ctismer:

Totally agree that there should only be one wrapper. That's why I replied to @sirphilip above.

 

When I started to write my wrapper the only option available was the one by Kevin. I decided not to use his wrapper because he would rely on the /gui/ which seems like a fragile implementation. From the time stamps looks like he wrote it before the API was available. So Kudos to him.

 

@tuxpoldo:

Why having imports is a problem? All imports are from the standard library except for requests. If you can show me a reliable reference saying that "way to much imports" is a problem I would be glad.

 

Also, yes, the wrapper I started does more then just "wrapping" the rest interface. It basically enables people to use sync as a protocol and not as an application. This was a requirement for me, if it is not a requirement for you, you can just disregard that part of the code. When using a python library do you need to use every single function of it? I guess not...

 

--------------------------------------

 

I really don't care about the which is better discussion, or why someone's code is better than someone else's code. The sync API is dead simple, a thin wrapper for it is 4 lines of code per function (pack url, request is, unpack json). Anyone who comes up with a reliable and feature rich implementation will have my full support.

 

At the moment I will have to keep using my code, because from all implementations it seems to be the only one that treats sync as a protocol and not as as desktop application.

I have been using my module for server deployments and it is a blast. I just need to run a python script and it will do everything I need: download sync, download all files I need, keep files and sync updated.

I have also been testing using my wrapper to deploy windows installers which would do the same. Download sync, download the application and shutdown sync.

 

As I said, I don't see sync as an application, but as a protocol (just like rsync). If someone comes up with a module that does what I need I will be happy to use it. It will be one less thing I need to maintain by myself. On the other hand if you find my code useful, you are welcome to contribute.

[tuxpoldo]

...

At the moment I will have to keep using my code, because from all implementations it seems to be the only one that treats sync as a protocol and not as as desktop application.

...

I fully agree on this. And this is exactly reason I wrote: "I'm not sure, that it's now the time to provide a central library that has to be updated, maintained, distributed in various distributions, etc... This would only slow down the application development..." and "...I am sure, that you would find lots of things in my code why you would never use it in your application."

Currently everybody of us has different requirements to such a library. Before starting the implementation of a general approach, we should understand all these requirements and the only way to do it, is to develop the first real life application in order to understand and collect our requirements.

Currently I think that after looking at all those libraries I can identify three main requirement categories:

 

1. Communication: thin API wrapper that communicates with a known running instance of BitTorrent Sync and provides all available API methods
2. Local process management: Facility that manages a well defined local environment of BitTorrent Sync including process start, stop, suspend, resume and protection against security issues, environmental issues (directory availability, configuration file, access rights to needed files and paths)
3. Deployment: Facility that manages the retrieval and installation of BitTorrent Sync in order to provide the prerequisites for the former two facilities to work...

e.g.: In my application, I need the first two of these. 

 

What do you think about this?

[tmac]

Currently I think that after looking at all those libraries I can identify three main requirement categories:

1. Communication.
2. Local process management.
3. Deployment.

What do you think about this?

 

I guess you are right. What do you propose?

[tuxpoldo]

I guess you are right. What do you propose?

 

I think that we should look also for the opinion of other developers here. All we currently know, is that both of us agree on these three main requirements to a standard BitTorrent Sync Library for Python. After we collected some more requirements, we may start by defining the interfaces of the needed classes....