On Sunday 20 June 2010 13.57.13 Adi Bier wrote:
> Hi Tobias,
> sorry for the delay, I'm very busy at the moment.
Yea, I know how it is. I'm not that quick either ;-)
> > I'm not sure it's a good thing to use a login to indicate that you're
> > available. Wouldn't it be better to use something like APRStt for that.
> > Then also visitors, that have no account, can indicate that they are QRV
> > on the node.
> hm, yes it's possible, but the dtmf-sequences of up to 16 digits from
> the stations, each time they want to send it's call or positioning beacons
> may cause the listeners to switch-off the radio. But ok, it maybe a way.
Yes, on a simplex fq that may be annoying but on a repeater one may see to
that the repeater does not open up on APRStt sequences.
> >> Incoming EchoLink connections could be treated as trusted (no
> >> password) and the user will be assigned to the guest-group if it has
> >> no svxlink.conf entry.
> > So you mean you want to send commands via chat messages or something
> > like that from a PC (e.g. using Qtel)?
> yes, it sounds interesting for me and I think it should be possible. And
> authentication has already being checked by the echolink-network.
> >> But what shall happen if an user is logging-in on different paths at
> >> the same time (phoneline AND RF-logic)? In this case the origin
> >> (logic) of the user request must be stored too.
> > There will be less need to be constantly logged in if not using it as an
> > available indicator. You log in, do your stuff and then log out. But of
> > course, multi login would be possible to implement if needed, but don't
> > make it more complicated than it needs to be.
> Hm, here I don't agree with you. I want to be connected with my repeater
> when I'm sitting at my bureau. There I have bad RF conditions, so a
> permanent network connection is the only way to listen to it. If you
> want to have sometimes digital extensions (mototrbo, tetra,...) within
> svxlink then the permanent registration/authentication of the mobile
> devices will be a point to discuss too. Connections to/from other
> services (SIP, self-made VoIP-apps) also need a permanent connection and
> Yes, it's hard to imagine at the moment how to realize authentication on
> classic FM-repeaters without any security options. But if we start with
> that, the auth-class should do it's job similary and independently from
> the logic or physical layer.
> > Yes, I've also been thinking of moving the config into a DB. It has some
> > advantages but also drawbacks. The obvious drawback is that the config
> > become less accessible and the need for a special config tool necessary.
> > I would not want to force users to learn SQL to be able to config
> > SvxLink. Even if there are general web interfaces to manipulate DB:s I
> > don't think this is a good solution. It will probably be too technical
> > for an average user to edit the tables and the risk of doing something
> > wrong is obvious. The correct thing would be to design a SvxLink web UI
> > that can present the SvxLink sysop with an easy to understand interface.
> > ...
> > Changing config "live" is something I have been thinking of as well.
> > This could be implemented in the Async::Config class by adding a SigC
> > signal for when a value is changed. The big job then, of course, is to
> > adapt different parts of SvxLink to handle live config updates.
> Yes, an additional "layer" in the Async::Config-class is at the moment
> the easiest way,
> ... but it's not the most important point that should be realized very
> soon ;-) It was just an idea, but I also see the problems coming up for
> somebody when setting up a DB server like postgresql first before
> installing svxlink.
I wonder if a "real" DB would be an advantage at all. The amount of data and
update rate will be very moderate. SQLite would be sufficient, don't you think?
If we need something more in the future, a move to another DB would be pretty
73' de SM0SVX / Tobias
> 73's de Adi, DL1HRC
> > 73's de SM0SVX / Tobias