wetube/bitcloud

Starting to code a demo, prototyping Tahoe-LAFS modifications

Closed this issue · 12 comments

Ok, so I think that we should start by taking the Tahoe-LAFS source code from here:

https://github.com/tahoe-lafs/tahoe-lafs

And start applying the ideas of CA management and publishers to construct a functional demo that we can present, as defined here:

https://github.com/wetube/bitcloud/blob/master/bitcloud.org

We have 2 approachs now to decide:
1.- Do the demo in Python based on current Tahoe-LAFS source code.
2.- Rewrite it completely in C (or other language).

I'd like to know what do you think. Please don't stay silent!
Everyone watching the repo please answer.

I think we should do both in that order, or just do approach 2 if noone experienced with python here.

Stick with the same language. Rewrites will introduce unexpected bugs as
artifacts of the rewrite process.

On Wed, Feb 5, 2014 at 9:41 AM, gga01 notifications@github.com wrote:

I think we should do both in that order, or just do approach 2 if noone
experienced with python here.

Reply to this email directly or view it on GitHubhttps://github.com//issues/33#issuecomment-34215690
.

Comment from a watcher

Hm, usually I'd say to stick with the language you opted for (that is, C), to reduce dependencies.

On the other hand, rewriting can introduce regressions. But C has the advantage over Python to not use a GC and hence can perform better. When looking at the code frequency I'm not sure, how actively maintained the project is. Do they have an IRC channel to get in touch? Maybe evaluating their roadmap first?

I'm watching this project from a Diaspora* PoV. Maybe it's compatible in the future :-)
Note, that I'm not an official maintainer, but enthusiast, though ;-)

Especially if this is just a demo, it's probably best to stick with Python.

Then, when we have a concrete system that we all know will work, we can develop a C API!

I think it would be easiest to proceed with a BitCloud PoC using Python. My experience with Python makes me think it's a fairly generic language. It can be compiled - to binary or even to C.

That said, I'd still like to port the platform to other languages. However, a protocol such as BitCloud should be defined sufficiently to be language independent.

The Tahoe-LAFS code is completely new to me, so I would counter advice translating it at this stage.
Does anyone know whether you can link to python code from C - for demo purposes this could suffice? I'll have a quick look - but please share if you know a solution.

I have quite a bit of experience in Python. I also agree that rewrites will not be a good idea. There are some clever ways around it that are being discussed and these could also work although it would make it bigger and clunkier. I think we need to decide from the beginning what language we are going to use and continue from there that way we don't have to worry about switching, rewriting, or linking anything at all.

I've asked a fellow Python coder, wether it is possible to compile Python to C.

He pointed me to this StackOverflow question although it usually does not cover his topic. Maybe it's worthy in the decission process :-)

Cython.

Obviously, it isn't going to be much better than compiling straight to assembly from python (e.g., py2exe or pypy), but it'll provide a start to work with. Personally, I'd rather model the software out and re-code it from the ground up (one part at a time) - and I'd port it to more than just C/++ in the process (e.g., Java).

I'm with what I see the majority suggesting, which is mostly the push to begin coding now with Python. (I'd prefer to see some more models of what we are shooting for first, but coding is always enjoyable when time allows.)

http://docs.python.org/2/extending/embedding.html

Python can be called from C. I first need to read on the architecture of Tahoe-LAFS before I can say whether it's feasible to embed, as it seems Tahoe-LAFS is written as a stand-alone project, not as an API (obviously when choosing Python).

Regardless, I'd prefer C as a base language of Bitcloud. I can't see how you can make it work in Python.

I also think that Python can be used for the demo.

But I don't think that Python could support the load of thousands of
nodes working together. Compiling Python to C is not an option because
that is still very experimental.

There is another reason to rewrite in C in the future: we need Bitcloud
to be lightweight so it can be used in routers and embedded devices, and
even phones (when we go full meshnet).

Ok, it seems that almost everybody agrees to use Python for the demo, and then convert to C for the final version. That doesn't mean that the Python version would be "dead", it can be maintained by the pythoners at the same time we do the C version, so we have two clients, which I think it is a good thing.

I'm going to work this weekend to integrate the source code in our repo and do some renames, change some papers in the Tahoe documents, delete unnecessary things, etc.

My recommendation for now: download, compile and test tahoe so you have a good overview of what we are going to do. The next week we should start with some coding.

We also must define more concretely what is the node pool and how to sync it, so you can start thinking solutions.

To everybody watching the repo but don't want to participate publicly, please contact me personally so I can coordinate efforts.