Command line driver

[Dmitry Yakimenko]

Hi!

I started developing the command line driver for the library. I just started the work, so there's not yet much progress to show. Just a foot in the door kind of message. Don't want someone developing something similar in secrecy and wasting efforts =)

The code is in my fork: https://github.com/detunized/clearskies_core

There's not much to review yet. Any ideas and/or suggestions are more than welcome.

Dima.

[Cotton Seed]

I've written a rudimentary control interface: client (in python) and
server (in C++). They're in a repository mixed up with some other
changes and I haven't had time to clean them up recently. I don't
particular care which one we use. My python client is attached.

Best,
Cotton

Dmitry Yakimenko:

[Cotton Seed]

Oops, I should note my version connects to localhost:6278 instead of
using a pipe. I was planning to fix it once I added support for pipes
on the server side in Daemon.

Cotton

Cotton Seed:

[Dmitry Yakimenko]

Thanks. I see in your Python client you're connecting to the daemon
via socket. The idea behind the C++ implementation that it would
include the CS code in the binary and would act as a
daemon/server/client maybe even a tracker in the future. Minimum
hassle deployment. A bit like Mercurial or Git. Everything in one
place.

Dima.

> --
> 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-de...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Steven Jewel]

On 04/15/2014 02:22 PM, Dmitry Yakimenko wrote:
> Thanks. I see in your Python client you're connecting to the daemon
> via socket. The idea behind the C++ implementation that it would
> include the CS code in the binary and would act as a
> daemon/server/client maybe even a tracker in the future. Minimum
> hassle deployment. A bit like Mercurial or Git. Everything in one
> place.

I think we'll want to support both ways. Let's call one the "embedded"
clearskies, and the other the "daemon".

On a desktop, I imagine the typical user would have a clearskies daemon,
controlled by a separate GUI. The GUI wouldn't necessarily always be
running. I'm also going to consider the command-line client to be a UI.
In all these cases, the control protocol would be used.

On mobile, clearskies would be embedded right into the application.
This would use an as-of-yet undocumented C API, let's call it
libclearskies. In this situation the GUI would be running in the same
process space, so there'd be no need to use the control protocol [1].

I propose that we unify things by having the daemon embed clearskies via
the libclearskies API. The control interface should be part of the
daemon, not part of the embeddable libclearskies. Therefore, the
control interface will be using the same API as an embedded client.
That way, we're "dogfooding" the API, which means that it will be a
first-class interface.

That, in turn, should make it easy to create a GUI.

So the control flow for adding a new share on a desktop would look
something like this:

GUI -> Control Socket -> Daemon -> libclearskies -> clearskies_core

Steven

P.S. Whether or not the clearskies-cli interface and the
clearskies-daemon ship inside the same binary or a separate one doesn't
matter to me. I'm just thinking about the internals.

[Dmitry Yakimenko]

Hi Hristo,

I started writing it but got a bit busy in real life. Also I was
waiting for Pedro to come back from vacation so we could discuss the
architecture of the project in detail. Now we've clarified some things
and I'm ready to move forward with the development of the driver
application. Currently it doesn't do much. Just shows help.

If you need something urgently you would have to hack something
together. I'm planning to add some basic features in the next few days
so it's possible to at least start the daemon. To control it we need
to refactor a bunch of things in the core.

Dima.

On Wed, Apr 30, 2014 at 6:31 PM, Hristo Asenov
<hristo....@gmail.com> wrote:
> Hi Dmitry,
>
> Is the command line driver that is in your repository on master branch in
> src/sky/main.cpp? I tried running it, however I couldn't figure out the
> right command to execute in order to start the daemon. It looks like the
> only two commands available are "help" and "version", and the main returns
> right after the handler on the command is invoked, so that start_daemon() is
> never invoked. Is it just a proof-of-concept code and not meant to init the
> daemon process at all, just test command line arguments? Would that mean
> that if I want to do something outside of running a unit test, I would have
> to write my own code to start the daemon?
>
> - Hristo

[Hristo Asenov]

Hello Dmitry,

Could you help me out with running the sky binary? What command line arguments do I need to have in order to invoke the start_daemon() function? It would be useful for me to be able to start the daemon outside of the unit tests. 

On Thursday, April 17, 2014 12:25:13 PM UTC-4, Steven Jewel wrote:

[Dmitry Yakimenko]

Currently it's not working. You can hack it to call Daemon::start and
Daemon::daemonize but I have not tried that yet, so I cannot tell you
if it works at all.

Dima.

[Pedro Larroy]

Even if you can start the daemon, still you can't synchronize yet. As the core protocol is not complete.

I'm refactoring the core so we can have independent message hierarchies for control, core etc. Which will also help for contributions.

Then I will finish synchronization and manifest transmission.

Meanwhile somebody else can help with SSL,  control, the tracker or with the protocol documentation.

Another task is to refactor protocol state to use 4bytes fixed size as discussed in the list before. I plan to do that as well soon.

Regards.

Pedro.

[Hristo Asenov]

Oh, I don't really want to synchronize, I just want to start the daemon and then use a client (using https://github.com/shish/python-clearskies or the script Cotton posted). I wanted to do this so I can put a breakpoint in the server using gdb and trace through the function calls in order to get a feel for how the whole thing works. 

[Pedro Larroy]

You need to create a binary for the daemon then, so far it's used only in a unit test test/daemon.cpp

Pedro.