C++ client planning

345 views
Skip to first unread message

Pedro Larroy

unread,
Jan 23, 2014, 9:44:33 AM1/23/14
to clearsk...@googlegroups.com
Hi

I would like top open the topic of the C++ client planning before rushing into coding.


So far I think we identified that we need:

* A json parser, the most reasonable seem sajson and gson. The rest aren't simple enough to maintain, performant or are in C. 
* An SSL library, GNUTls or PolarSSL according to the DHE feature required
* An asynchronous IO library such as libev or libevent.
* Boost filesystem library for portable path and fs access.
* C++11 features supported across g++ >= 4.7, clang and VS2012    this will allow us to use std::thread, smart pointers, auto and lambdas

Main platforms to support:  Linux, Mac, iOS, Android and Windows.

I think with these requirements we can build a solid C++ client.

What do you guys think?

Pedro.

Pedro Larroy

unread,
Jan 23, 2014, 9:52:58 AM1/23/14
to clearsk...@googlegroups.com
From the Design POW I would like to add, that I think we can do the network IO around the event loop, and use threads only when needed for a background task such as local fs scanning or checksumming, also when writing file data to a file, as we can't do asynchronous IO in the event loop with disk files.

Looks good?

Pedro.

Pedro Larroy

unread,
Jan 23, 2014, 11:55:27 AM1/23/14
to clearsk...@googlegroups.com
Json library:

This one looks quite nice and idiomatic C++, Boost license. 

http://sourceforge.net/p/jsoncons/wiki/Basics/

Has serialize and deserialize.



On Thursday, January 23, 2014 3:44:33 PM UTC+1, Pedro Larroy wrote:

Steven Jewel

unread,
Jan 23, 2014, 4:28:08 PM1/23/14
to clearsk...@googlegroups.com
On 01/23/2014 07:44 AM, Pedro Larroy wrote:
>
> * A json parser, the most reasonable seem sajson and gson. The rest
> aren't simple enough to maintain, performant or are in C.

I haven't had a chance to look into specific libraries yet (I'm on
vacation this week) but the protocol is simple enough to not place too
many constraints on what is acceptable.

> * An SSL library, GNUTls or PolarSSL according to the DHE feature required
> * An asynchronous IO library such as libev or libevent.

I'm not sure that libev, libuv, or libevent are portable to iOS, but we
can add support when we get to that point.

> * Boost filesystem library for portable path and fs access.
> * C++11 features supported across g++ >= 4.7, clang and VS2012 this
> will allow us to use std::thread, smart pointers, auto and lambdas
>
> Main platforms to support: Linux, Mac, iOS, Android and Windows.

There was recently an article about using chromium as a basis for
cross-platform applications that I thought was worth looking into.

https://www.mobilespan.com/content/chrome-is-the-new-c-runtime

Chrome is already running on all of the platforms we want, all building
from the same codebase. It has a lot of the libraries that we need, and
a build system already put together. Finally, the libraries they've
chosen will benefit from the large amount of security scrutiny that
chrome gets.

To be clear, what I'm suggesting is we take a copy of the chromium code,
and then strip out all the parts we don't need, and then build our app
on top of that.

I'm not sure if it's a good path, but I thought I'd suggest it so others
could see if it seems palatable. It'd be nice to have the software
building and releasing on all five platforms on day one.

Steven

Steven Jewel

unread,
Jan 23, 2014, 5:09:07 PM1/23/14
to clearsk...@googlegroups.com
On 01/23/2014 07:52 AM, Pedro Larroy wrote:
> From the Design POW I would like to add, that I think we can do the
> network IO around the event loop, and use threads only when needed for a
> background task such as local fs scanning or checksumming, also when
> writing file data to a file, as we can't do asynchronous IO in the event
> loop with disk files.

This should work great. We'll want to have a consistent way to make
sure that we can't have deadlocks or race conditions. This is the first
project where I used the "brain-dead" threads approach, and it worked
really well. Event-based code is nice because it doesn't need any locks
if there are no threads, so it's less of an issue.

The most obvious way to handle this would be similar to the current
system. We have a global lock that is only released when a thread is
doing things that are known to be safe, such as checksumming file data
that is thread-local.

The event loop code would hold the global lock while processing an event
but otherwise release it. This is especially appropriate for our daemon
because we might have several different event loops (one for the
network, and another for filesystem change events).

Note that this means that we won't use more than one core, but I think
that's OK because we're supposed to be a background job.

Steven

Pedro Larroy

unread,
Jan 23, 2014, 5:12:38 PM1/23/14
to clearsk...@googlegroups.com, clear...@stevenjewel.com
I read that article, and was browsing the code a bit:


It's definitely worth looking at and probably even borrow a couple of things when we need.

I have two concerns about this:

The guy that wrote the article was a former chromium developer, so he knows how to deal with the project, which is huge.
There's many many things that we don't need, we might as well borrow what we need and integrate carefully with our project instead. I think otherwise it can be difficult to manage and grow into a mess very quickly.

Just my opinion.

Pedro Larroy

unread,
Jan 23, 2014, 5:19:57 PM1/23/14
to clearsk...@googlegroups.com, clear...@stevenjewel.com
We should we need to introduce a global lock?  If we start changing data structures from different threads is the recipe for races, disaster when debugging and for bad peformance.

We use worker threads only for doing disk IO inside a file transfer after the json chunk has been processed. There's no need for locks in those cases, as the main thread is the only one that touches control data structures, and the disk IO thread uses exclusively a pair of filedescriptors handled by the main thread. When that task is finished, the thread ends.

The worker threads don't need to touch any data structure which is handled exclusively by the man thread in the eventloop in responses to messages or timed events.

Actually your design of the protocol with the metadata in json as a prefix would make this beautifully possible.

Pedro Larroy

unread,
Jan 23, 2014, 5:26:48 PM1/23/14
to clearsk...@googlegroups.com, clear...@stevenjewel.com
Just to clarify what I mean:


main thread is sleeping on the event loop.
Data is read asynchronously until we have a complete json message, then is handled by the same thread, control data structures such as "@share" are handled by the main thread.
If there's more data coming such as binary payload that needs to be written to secondary storage, then a worker thread is started and finished when we are over with the payload.

For the scanner thread we can just send control messages over a pipe to the main thread, thus avoiding any need for locks.


Pedro.

Steven Jewel

unread,
Jan 23, 2014, 5:47:00 PM1/23/14
to Pedro Larroy, clearsk...@googlegroups.com
On 01/23/2014 03:26 PM, Pedro Larroy wrote:
>
>
> main thread is sleeping on the event loop.
> Data is read asynchronously until we have a complete json message, then
> is handled by the same thread, control data structures such as "@share"
> are handled by the main thread.
> If there's more data coming such as binary payload that needs to be
> written to secondary storage, then a worker thread is started and
> finished when we are over with the payload.
>
> For the scanner thread we can just send control messages over a pipe to
> the main thread, thus avoiding any need for locks.

Yes, this will work as well. It's similar to the way that WebWorkers
work, as well as channels in golang.

I believe it's the same end result, and you're right that it'd be easier
to debug if everything is on the main thread.

One thing that I'm not sure how to do is have the main thread wait for
events from libev while simultaneously waiting for messages from the
worker threads. It'd be nice to use a threadsafe queue for message
passing between threads. Perhaps we can have libev reading be in a
thread, and have that be serialized into a single queue for the main
thread to process.

In any case, easy enough to play around with as we're actually writing
the code.

Steven

Pedro Larroy

unread,
Jan 23, 2014, 7:16:57 PM1/23/14
to Steven Jewel, clearsk...@googlegroups.com
You can open a pipe, socket or a fifo and add it to the event loop. Actually this is better than using a queue as the event loop would have to poll it with a callback, as it spends most of the time suspended on the poll loop. 
--
Pedro Larroy Tovar   |    http://pedro.larroy.com/

Steven Jewel

unread,
Jan 24, 2014, 12:17:01 AM1/24/14
to Pedro Larroy, clearsk...@googlegroups.com
On 01/23/2014 05:16 PM, Pedro Larroy wrote:
> You can open a pipe, socket or a fifo and add it to the event loop.
> Actually this is better than using a queue as the event loop would have
> to poll it with a callback, as it spends most of the time suspended on
> the poll loop.

OK, that works for me. The actual inter-thread communication mechanism
would probably be encapsulated in a class, so if we have to change it
out on some platforms or to increase performance then it won't be a big
deal.

Steven

Pedro Larroy

unread,
Jan 24, 2014, 10:12:23 AM1/24/14
to clearsk...@googlegroups.com, Pedro Larroy, clear...@stevenjewel.com
Hi

Another issue is that given the current protocol the requests for the tracker are HTTP. We would need an HTTP library like curl for this. Do we really need http? Why not a simple connection with an additional message to do what the GET request does? This would simplify the client by not requiring an HTTP library. I would prefer it that way.  I understand that this was not an issue when using ruby.

Pedro.

Steven Jewel

unread,
Jan 24, 2014, 11:50:17 AM1/24/14
to Pedro Larroy, clearsk...@googlegroups.com
On 01/24/2014 08:12 AM, Pedro Larroy wrote:
> Hi
>
> Another issue is that given the current protocol the requests for the
> tracker are HTTP. We would need an HTTP library like curl for this. Do
> we really need http? Why not a simple connection with an additional
> message to do what the GET request does? This would simplify the client
> by not requiring an HTTP library. I would prefer it that way. I
> understand that this was not an issue when using ruby.

Good simplification. We can change the tracker to use the same wire
protocol as everything else, which will simplify the spec and make it
always be in "fast tracker" mode.

As usual, I've added a card in trello so that I don't forget to address
this before the first non-alpha release.

Steven

Pedro Larroy

unread,
Jan 24, 2014, 11:54:41 AM1/24/14
to clearsk...@googlegroups.com, Pedro Larroy, clear...@stevenjewel.com
Do we have a wiki for the project? when I click on "wiki" in github it does nothing.

I think it would be good to have it.

Pedro Larroy

unread,
Jan 24, 2014, 11:55:14 AM1/24/14
to clearsk...@googlegroups.com, Pedro Larroy, clear...@stevenjewel.com
I massaged a bit this json library to build on linux and pass the tests:


Pedro.

Pedro Larroy

unread,
Jan 24, 2014, 6:19:43 PM1/24/14
to clearsk...@googlegroups.com, Pedro Larroy, clear...@stevenjewel.com
I started putting together stuff in this repo:

Steven Jewel

unread,
Jan 25, 2014, 12:01:49 AM1/25/14
to clearsk...@googlegroups.com, Pedro Larroy
On 01/24/2014 09:54 AM, Pedro Larroy wrote:
> Do we have a wiki for the project? when I click on "wiki" in github it
> does nothing.
>
> I think it would be good to have it.

We do have a wiki, it is just empty.

It sounds like you can't submit pull requests through the github
interface for wiki content, but there is a workaround that will work for
our project as well:

http://fusiongrokker.com/post/how-you-can-contribute-to-taffy-documentation

Steven

Steven Jewel

unread,
Jan 25, 2014, 12:08:32 AM1/25/14
to Pedro Larroy, clearsk...@googlegroups.com
On 01/24/2014 09:55 AM, Pedro Larroy wrote:
> I massaged a bit this json library to build on linux and pass the tests:
>
> https://github.com/larroy/jsoncons

The syntax of jsoncons looks simple enough at first glance. I have been
on the road and haven't had a chance to take an in-depth look at the
various JSON libraries proposed yet, so sorry for not having more
feedback yet.

Steven

Pedro Larroy

unread,
Jan 25, 2014, 5:39:57 AM1/25/14
to clearsk...@googlegroups.com, Pedro Larroy, clear...@stevenjewel.com
I evaluated several async IO libraries and I think libuv can serve us well, it's multiplatform, people have used it in the platforms we want to support and I have checked the main code paths that we are going to use and look ok.

Also there are some examples around from people using it with SSL. I have never used SSl so I investigated that you can create an ssl context to write and read from if you don't want to "upgrade the socket" as you need the socket for your async library:


Any concerns in the SSL side?


Pedro.

Steven Jewel

unread,
Jan 25, 2014, 11:10:35 AM1/25/14
to Pedro Larroy, clearsk...@googlegroups.com
On 01/25/2014 03:39 AM, Pedro Larroy wrote:
> I evaluated several async IO libraries and I think libuv can serve us
> well, it's multiplatform, people have used it in the platforms we want
> to support and I have checked the main code paths that we are going to
> use and look ok.

I've been comparing by looking at the implementation of an "echo"
server. Here is one for libuv:

https://github.com/joyent/libuv/blob/master/test/echo-server.c


Here is another for boost.asio:

http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/example/allocation/server.cpp


Here's a third for POCO:

http://poco.sourcearchive.com/documentation/1.3.6p1-1/samples_2EchoServer_2src_2EchoServer_8cpp-source.html


I'm having a hard time deciding which would be better. With libuv we'll
need to make our own C++ dispatcher in order to implement the reactor
pattern.

Another possibility would be to make the C++ code threaded to start out
with. clearskies only requires maybe ten threads per share in order to
work [1].

> Also there are some examples around from people using it with SSL. I
> have never used SSl so I investigated that you can create an ssl context
> to write and read from if you don't want to "upgrade the socket" as you
> need the socket for your async library:
>
> https://gist.github.com/larroy/8596922
>
> Any concerns in the SSL side?

I don't foresee any problems with SSL. Integrating with GnuTLS was easy
to do in ruby, even when the underlying socket was a uTP socket instead
of a native TCPSocket. You can manage all the communication with the
socket yourself using gnutls_transport_set_pull_function and
gnutls_transport_set_push_function.

Steven

[1]: While it's possible to have a share with hundreds or thousands of
participants, it's not advisable to connect to all of them. Picking a
handful at random is better.

listas....@gmail.com

unread,
Jan 25, 2014, 3:25:56 PM1/25/14
to clearsk...@googlegroups.com, Pedro Larroy, clear...@stevenjewel.com
Hi Pedro

Which OS/g++ version are you using?

I forked and cloned your repo in Debian 7.1 (wheezy) with gcc version 4.7.2 (Debian 4.7.2-5) and build is failing (errors below).

I don't have experience working with c++11, something that I am missing?

Regards
Luciano

dev@debian01:~/work/clearskies_core$ ./build.sh 
ninja: Entering directory `out/Default/'
[1/2] g++ -MMD -MF obj/test/unit_test.message.o.d  -I../../src -std=c++11 -Wnon-virtual-dtor -Wno-deprecated   -c ../../test/message.cpp -o obj/test/unit_test.message.o
FAILED: g++ -MMD -MF obj/test/unit_test.message.o.d  -I../../src -std=c++11 -Wnon-virtual-dtor -Wno-deprecated   -c ../../test/message.cpp -o obj/test/unit_test.message.o
In file included from ../../test/message.cpp:18:0:
../../src/cs/message.h:54:38: error: expected ‘;’ at end of member declaration
../../src/cs/message.h:54:42: error: expected unqualified-id before ‘=’ token
../../src/cs/message.h:55:33: error: expected ‘;’ at end of member declaration
../../src/cs/message.h:55:37: error: expected unqualified-id before ‘=’ token
../../src/cs/message.h:77:5: error: ‘jsoncons’ does not name a type
../../src/cs/message.h: In member function ‘ConcreteMessageType message::Message::refine()’:
../../src/cs/message.h:63:47: error: ‘json’ was not declared in this scope
../../src/cs/message.h: At global scope:
../../src/cs/message.h:78:2: error: multiple types in one declaration
../../src/cs/message.h:89:5: error: ‘u32’ does not name a type
../../src/cs/message.h: In constructor ‘message::Ping::Ping()’:
../../src/cs/message.h:84:9: error: class ‘message::Ping’ does not have any field named ‘m_timeout’
../../src/cs/message.h:84:19: error: no matching function for call to ‘message::Message::Message()’
../../src/cs/message.h:84:19: note: candidates are:
../../src/cs/message.h:53:5: note: constexpr message::Message::Message(message::Message&&)
../../src/cs/message.h:53:5: note:   candidate expects 1 argument, 0 provided
../../src/cs/message.h:52:5: note: constexpr message::Message::Message(const message::Message&)
../../src/cs/message.h:52:5: note:   candidate expects 1 argument, 0 provided
../../test/message.cpp: At global scope:
../../test/message.cpp:24:11: error: ‘ping_message’ does not name a type
../../test/message.cpp:26:11: error: ‘invalid_message’ does not name a type
../../test/message.cpp:29:21: error: expected constructor, destructor, or type conversion before ‘(’ token
../../test/message.cpp:40:21: error: expected constructor, destructor, or type conversion before ‘(’ token
ninja: build stopped: subcommand failed.

Pedro Larroy

unread,
Jan 25, 2014, 4:01:39 PM1/25/14
to listas....@gmail.com, clearsk...@googlegroups.com, Steven Jewel

Currently is not building. There's not much yet.

Pedro.

Steven Jewel

unread,
Jan 27, 2014, 12:51:59 PM1/27/14
to clearsk...@googlegroups.com, Pedro Larroy
On 01/24/2014 04:19 PM, Pedro Larroy wrote:
> I started putting together stuff in this repo:
>
> https://github.com/larroy/clearskies_core

Looks good.

I have added a link to your repository in the main README.

Steven

Steven Jewel

unread,
Feb 5, 2014, 10:50:01 AM2/5/14
to Pedro Larroy, clearsk...@googlegroups.com
On 01/24/2014 08:12 AM, Pedro Larroy wrote:
> Another issue is that given the current protocol the requests for the
> tracker are HTTP. We would need an HTTP library like curl for this. Do
> we really need http? Why not a simple connection with an additional
> message to do what the GET request does? This would simplify the client
> by not requiring an HTTP library. I would prefer it that way. I
> understand that this was not an issue when using ruby.

HTTP is finally gone, in the "protocol_cleanup" branch:

https://github.com/jewel/clearskies/blob/protocol_cleanup/protocol/core.md#tracker-protocol

I can rewrite the server-side tracker once we have a client that's ready
for it.

Steven

pirmin....@gmail.com

unread,
Feb 24, 2014, 6:00:29 AM2/24/14
to clearsk...@googlegroups.com
Hi,
Probably too late, but what about skipping C++ and going for Rust?
See also Yehuda Katz' talk about using Rust with a Ruby interface [1].

Regards
Pirmin

[1] https://air.mozilla.org/sprocketnes-practical-systems-programming-in-rust/ (73:30)

Steven Jewel

unread,
Feb 24, 2014, 11:01:55 AM2/24/14
to clearsk...@googlegroups.com
On 02/24/2014 04:00 AM, pirmin....@gmail.com wrote:
> Probably too late, but what about skipping C++ and going for Rust?
> See also Yehuda Katz' talk about using Rust with a Ruby interface [1].
>
> Regards
> Pirmin
>
> [1] https://air.mozilla.org/sprocketnes-practical-systems-programming-in-rust/ (73:30)
>

I considered it but since it's not hit 1.0 yet, I wasn't sure if it was
quite ripe enough to handle clearskies, since clearskies is aiming to
work on Android, iOS, Linux, and Windows from the get-go.

It will be enough work to support these four platforms in a supported
language (C++) without having to additionally worry about getting the
language to compile for the platform.

That being said, if someone wanted to start a rust implementation of the
clearskies protocol, I'd be happy to link to it from the main repository.

Steven

Pedro Larroy

unread,
Feb 24, 2014, 12:03:30 PM2/24/14
to clearsk...@googlegroups.com
The more implementations the better. I think it would be better to focus the effort on having a solid multiplatform client. And that leads us to the C++ implementation effort.

We are using very modern C++11 at the cost of requiring fairly new compilers, which makes it much more palatable and less amount of code than C, C+ or C++. It's a complex language but very powerful and fast.


Pedro.






--
You received this message because you are subscribed to the Google Groups "ClearSkies Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clearskies-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Pedro Larroy

unread,
Feb 28, 2014, 2:14:25 PM2/28/14
to clearsk...@googlegroups.com
Hi

Given the description of the protocol, the client specifies the share id on the greeting. Does that mean that we need one connection per share?  Should we or shouldn't we support switching to another share in the same connection?


Pedro.

Steven Jewel

unread,
Feb 28, 2014, 2:34:06 PM2/28/14
to clearsk...@googlegroups.com
On 02/28/2014 12:14 PM, Pedro Larroy wrote:
>
> Given the description of the protocol, the client specifies the share id
> on the greeting. Does that mean that we need one connection per share?
> Should we or shouldn't we support switching to another share in the
> same connection?

I don't think it's worth the complexity to multiplex multiple shares
into a single connection.

The way I'm proposing to do SRP authentication will need a single
connection for each share anyway:

https://github.com/jewel/clearskies/blob/protocol_cleanup/protocol/core.md#connection

Steven

Pedro Larroy

unread,
Jul 4, 2014, 8:44:17 AM7/4/14
to clearsk...@googlegroups.com
I'm not satisfied with how the C++ client is going. I didn't getmuch help with it and I think now going with rust or scala would make the code much better.

I think the payload format is not the best as you can't interleave messages when a big transfer is in progress.

With the current amount of contributions is not realistic for me to finish the C++ client alone.

If there is enough interest we can do a reset and rebuild it in rust or scala.


Pedro

Steven Jewel

unread,
Jul 4, 2014, 9:14:17 PM7/4/14
to clearsk...@googlegroups.com
On 07/04/2014 06:44 AM, Pedro Larroy wrote:
> I'm not satisfied with how the C++ client is going. I didn't get much
> help with it and I think now going with rust or scala would make the
> code much better.

I'm sorry I haven't been more help.

What are the major things left to do?

> I think the payload format is not the best as you can't interleave
> messages when a big transfer is in progress.

This was intentional; sophisticated clients can request files in pieces
using range requests OR they can open multiple simultaneous connections.
Simple clients wouldn't have to worry about interleaving. I'm open to
changing this.

> With the current amount of contributions is not realistic for me to
> finish the C++ client alone.
>
> If there is enough interest we can do a reset and rebuild it in rust
> or scala.

Scala doesn't run on iOS. I'm OK with ditching iOS support for the
initial version, but it will mean that someone will have to make a obj-c
or swift port.

I like rust from what I've seen of it, but it seems like the language is
still in a lot of flux and might not be a good base to build upon yet.
It's a good candidate as it's obviously extremely portable and can
interop with C, meaning it'll work for iOS and Android.

It's too bad there's not a higher-level language that is as portable as
C and C++. In all seriousness, I think it'd work fine to write the
initial version of the code in Javascript, and then replace
performance-sensitive portions with C++ as are found with a profiler.

Lua seems like it'd be close to this, but I don't have any experience
with it. Lua will run anywhere that C will run. What I was thinking is
that the core behavior would be written in Lua, and then C bindings
would be made for the OS-level portions that needed to be interacted
with where bindings don't already exist.

Finally, I also played briefly with mruby, which is an embeddable
version of ruby. It's similar in spirit to lua.

Steven

Pedro Larroy

unread,
Jul 5, 2014, 5:40:28 AM7/5/14
to clearsk...@googlegroups.com

Actually it might be possible to to run Scala with avian in iOS.

The guys of syncthing are quite advanced, they have an android client already.

If we don't have enough resources might be best to join them.

Pedro.

--
You received this message because you are subscribed to the Google Groups "ClearSkies Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clearskies-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

André Pereira

unread,
Jul 13, 2014, 10:09:39 AM7/13/14
to clearsk...@googlegroups.com
For me, the biggest advantage of ClearSkies-core over SyncThing, which seems to be the only other reasonable open source distributed cloud platform, is that it is (or will be) a C++ compiled library. I'd have to say that if the ClearSkies project changes direction on this, I'm out.

Or rather, maybe your solution of joining forces is a good one, but I don't think we need another High level language, JIT "compilation", Bytecode/JVM, errors only on runtime, core library: what's the point?
To unsubscribe from this group and stop receiving emails from it, send an email to clearskies-de...@googlegroups.com.

Pedro Larroy

unread,
Jul 13, 2014, 12:13:14 PM7/13/14
to clearsk...@googlegroups.com

Hi André

I'm studying the conflict resolution logic of St.

They provide binaries for several architectures including a WIP android client.

Everyone has a preference of programming language and they use go.  The question is should we be divided because of language preferences or join forces to reach the common goal of both projects?

Btw Scala is statically typed. So the errors at runtime are not like with dybamically typed languages. What advantage other that. IOS does CPP give us?

Pedro

André Pereira

unread,
Aug 11, 2014, 8:24:08 AM8/11/14
to clearsk...@googlegroups.com
Scala runs on JVM, so for practical (non-development purposes) you'd be adding the Java requisite and all that it entails (big overhead, framework dependency). Take BTsync for example, they implemented the hell out of their C++ clients and it runs smoothly with no specific requirements even on a Raspberry Pi.

But I'm no IT expert, and wouldn't dream of imposing anything. I think most of us came to ClearSkies by the same personal wishes: an open-source BTSync and that's what we should be aiming for, especially since SyncThing is already doing the niche language/weird dependencies approach, why do the same again just in another high level language with different weird dependencies?

PS: sorry for the late reply, lots of stuff going on.

Pedro Larroy

unread,
Aug 11, 2014, 9:14:40 AM8/11/14
to clearsk...@googlegroups.com
What do we gain now that syncthing is already more mature? I think it's better to have just one project instead of divide the community in two.  Anyways, the code so far is open source and anybody can do whatever they want inside the terms of the license.

Another question is what if we  should use the funds that were donated to the C++ client towards syncthing?  Does anybody has an inconvenient about that?


Pedro.

Dmitry Yakimenko

unread,
Aug 11, 2014, 10:15:38 AM8/11/14
to clearsk...@googlegroups.com
I think money should be given back to the donors.

Pedro Larroy

unread,
Aug 11, 2014, 10:19:16 AM8/11/14
to clearsk...@googlegroups.com

Does bountysource support this?
The target of both projects is the same,  to have an open source sync program.

Pedro

Dmitry Yakimenko

unread,
Aug 11, 2014, 10:27:25 AM8/11/14
to clearsk...@googlegroups.com
I think it's up each donor to decide if they want to donate elsewhere.
That would be my opinion.

Pedro Larroy

unread,
Aug 11, 2014, 10:55:37 AM8/11/14
to clearsk...@googlegroups.com
Yes if any donor wants a reimbursement, I can can arrange.

We can either, keep pushing the C++ client if there's enough interest, which doesn't seem to be or  send the funds towards syncthing.

Is there any interest to finish the C++ client? to me it doesn't make sense given the status of syncthing.

Pedro.
Reply all
Reply to author
Forward
0 new messages