From: Andrew Lunn <andrew@lunn.ch>
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: Wed, 9 Oct 2013 23:48:10 +0200 [thread overview]
Message-ID: <20131009214810.GB14447@lunn.ch> (raw)
In-Reply-To: <70C9D015-5815-4EDA-A427-F496906D18EE@dymos.org.uk>
On Wed, Oct 09, 2013 at 05:34:00PM +0100, Stephen Thornton wrote:
Hi Stephen
Please could you fix your mail client to keep lines short than around
70 characters.
> 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.
> 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.
Are you interested in using alfred, or vis built on top of alfred?
Would you want a library for accessing alfred, or for accessing vis?
You could pull some of the boilerplate code out of vis and my
alfred-gpsd server/client into a library. e.g. alfred_open_sock(),
_publish_data(), _request_data(), _receive_answer_packet(),
_get_data(). What will cause problems is the globals structure. It is
a mixture of generic and application specific members. That will
require quite a bit of refactoring.
I'm just not sure it is worth the effort. It took me less than a
mythical man day to get a proof of concept gpsd code working, and
another day to sort out output formatting issues and the odd bug, etc.
Creating a new client/server embedded in some other application is not
particularly difficult, re-using the existing code.
Andrew
next prev parent reply other threads:[~2013-10-09 21:48 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 [this message]
2013-10-10 12:58 ` Simon Wunderlich
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=20131009214810.GB14447@lunn.ch \
--to=andrew@lunn.ch \
--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