rlm_protobuf as alternative rlm_rest: Re: Backporting rlm_rest to 2.1.x

[Ruslan Shevchenko]

  btw,  you can look on freeradius-protobif module, which have
functionality very close
to rlm_rest (generic bridge but for protobuf over http  instead rest)
and have supported branch for freeradius-2.1
(see  https://github.com/rssh/rlm_protobuf/ - master is compatible
with 3.0,  freeradius-2.1.x - with 2.1.x)
This work in production for my of one clients.

On Sat, Aug 11, 2012 at 6:34 PM, Gavin Alves <gavin.alves at gmail.com> wrote:
>> how do you designate 'mature' software?  old software can and does have
>> bugs too -
>> well used software might be 'mature' in way of updates/patches but then
>> you
>> have no features.   we need more people to be running 3.0 so that we can
>> find
>> any other issues and maybe see a sooner release or 3.0.1 etc
>>
>> I've only running 3.0 HEAD on my test systems now - no longer looking at
>> 2.1.x or
>> 2.2.x updates - and it wont be long before it'll be just 3.x on production
>> systems
>> too.
>
>
> Point taken.  The reality is that many organisations will not upgrade
> software until there are packages maintained in their distro, By this point
> a business can assume at least some minimum standard of 3rd party quality
> assurance and peer review.  A really strong case would be needed for a home
> brew release (which I don't think I could make as 2.1 works very well for
> us).
>
> As for getting people onto 3.0; a classic catch 22.  Updating the website,
> api docs, distributing binary packages and so on might help.  I was not even
> aware of it until yesterday.
>
>
>
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/devel.html