[Loco-dev] concerning locod

[TOK]

greetings everyone,

i tried working on the locod (after some smalltalk with arne), got a few
things done and a lot of new questions.

changes to loco.h
i added loco_get_local_ips (from address.c). i don't understand while
loco-msg does compile (without), but copy and paste brought this up.
shall i use this at all?

created locod subdir with:
locod.h - types, errors and global var (pointer)
config_parser.c - so we don't need to specify key, bootstrap ... as
arguments. i think we will surely need something like this.
locod.conf - xml style

daemon.c - ripped of loco-msg.c (pretty much nothing here)
starter.c - get & use params, load config, start daemon.c::locod_run()

i will update to cvs sometime this night, short of any wonders this code
will NOT compile (thus not included in loco-make, try make in locod).
i do this, as i try to prevent the same code written twice and think are
and me (or anyone) needs some base to start from (or so to say: sorry
about broken code).

i would continue on something like this:
-in server_func (of locod):
await con, depending on port (number) give to registered loco app (if
allowed by policy), allow apps to un/register (internal communication
port), something on loco external contact port?

something about listing loco services on different ports?

if i understood arne correctly, a app can register to locod with the
desired external port. locod starts listening on that port, negotias
another port with the app and does:
(ext_port) <-> [locod] <-> (int_port) <-> loco_app

i would assume, an app registers with some kind of service name
'message', 'messanger', 'file-sharing' and locod does some lookup
(/etc/services) to get the port (locally assigned).

that ok?

assuming i would change LocoData (add an int or trivial as such), what
functions would break (parse_progressive, parse_data)?
how to prevent?

about filesharing:
i have some lines for escaping binary data for usage as strings
(currently trying to yencode [www.yenc.org], very little overhead
compared to base64), though it's not completely working.
some further tries to create (and manage) a number of xml sets (per
transfered file, one index and several data chunks) to transfer data as
strings.

about a database:
i pretty sure it's no good to use mysql/psql in a library, but would
help storing large amount of data on gpg keys, ips and such.
especially concerning info used for file sharing and keeping it
consistent after a (locod) crash would imho be a lot easier.

cu, tok