From: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
To: The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] a question regarding ALFRED
Date: Thu, 10 Oct 2013 14:58:57 +0200 [thread overview]
Message-ID: <20131010125857.GA31659@pandem0nium> (raw)
In-Reply-To: <70C9D015-5815-4EDA-A427-F496906D18EE@dymos.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]
Hello Stephen,
On Wed, Oct 09, 2013 at 05:34:00PM +0100, Stephen Thornton wrote:
> I am currently developing a mesh router solution for several clients. I have been using batman-adv in this project for almost a year (using OpenWRT), and it has all worked fantastically. Thanks so much guys.
thank you :)
> I now have a requirement for GPS logging functionality, along with passing other data between nodes. I have already written a simple layer3 protocol for this purpose, but this was before ALFRED. ALFRED provides almost all the functionality I need apart from the fact that I really need to embed the alfred code within my own application. I could use it as is via a sys call, but it would be so much better to include the code. What are your feelings regarding splitting the alfred code into a library with can be included in other user applications, and an alfred client program that uses this library? I'm quite prepared to give quite a bit of my own time to doing this if you like the idea.
Well, the alfred binary does quite a few things and relies on being a process on it's own. I don't think
it's easy to integrate that functionality in a library, and it is not intended.
What we'd like to encourage however is to interface directly with alfred by talking to it through
the unix socket - have a look at vis (already implemented) or the gpsd support andrew recently
proposed. You could do the same for your application - talk to alfred directly. That should also
be the best solution in regard of long term maintainance, license issues (alfred is GPL after all), ...
If you feel that alfred really needs to be binary-integrated in your application, I'd like to know why. :)
Cheers,
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2013-10-10 12:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-04 15:16 [B.A.T.M.A.N.] [PATCH v2] alfred: Add support for passing location information over alfred Andrew Lunn
2013-10-09 16:34 ` [B.A.T.M.A.N.] a question regarding ALFRED Stephen Thornton
2013-10-09 21:48 ` Andrew Lunn
2013-10-10 12:58 ` Simon Wunderlich [this message]
2013-10-13 21:51 ` [B.A.T.M.A.N.] [PATCH v2] alfred: Add support for passing location information over alfred Simon Wunderlich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131010125857.GA31659@pandem0nium \
--to=simon.wunderlich@s2003.tu-chemnitz.de \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox