librelist archives

« back to archive

Radicale 1.0 is coming, what's next?

Radicale 1.0 is coming, what's next?

From:
Date:
2015-08-21 @ 16:46
Hello everyone,

Radicale 0.10 is a bit old, and it's time for another release. I'll 
release
this new version next week, and I've decided to call it 1.0, because:

- there are no big changes since 0.10 but some small changes are really 
useful,
- simple tests are now automatically launched on Travis, and more can be
  added in the future (https://travis-ci.org/Kozea/Radicale).

This 1.0 version will be maintained with only simple bug fixes on a 
separate
git branch.

Once this milestone is reached, it's time to think about the future. 
When
Radicale has been created, it was just a proof-of-concept. The main 
goal was
to write a small, stupid and simple CalDAV server working with 
Lightning, using
no external libraries. That's how we created a piece of code that's 
(quite)
easy to understand, to use and to hack.

The first lines have been added to the SVN (!) repository as I was 
drinking
beers at the very end of 2008. It's now packaged for a growing number 
of Linux
distributions. And that was fun going from here to there thanks to you.

Things have changed, many users now rely on Radicale in production. For
example, I use it to manage medical calendars, with thousands requests 
per day.
Many people are happy to install Radicale on their small home servers, 
but are
also frustrated by performance and unsupported specifications when 
they're
trying to use it seriously.

I think that Radicale 2.0 should:

- rely on a few external libraries for simple critical points (dealing 
with
  HTTP and iCal for example),
- be thread-safe,
- be small,
- be documented in a different way (for example by splitting the client 
part
  from the server part, and by adding use cases),
- let most of the "auth" modules outside in external modules,
- have more and more tests,
- have reliable and faster filesystem and database storage mechanisms,
- get a new design :).

I'd also secretly love to drop the Python 2.x support.

These ideas are not all mine (except from the really, really, really 
important
"design" point :p), they have been proposed by many developers and 
users.
I've just tried to gather them and keep points that seem important to 
me.

What do you think of that? I'm sure that you now want to:

- tell that issue #X or pull request #Y should be closed before 1.0,
- discuss these points and add your owns,
- propose your favorite libraries.

I'll be glad to read your mails!
-- 
Guillaume

Re: [radicale] Radicale 1.0 is coming, what's next?

From:
alex.
Date:
2015-08-22 @ 17:18
I just want to say thank you very, very much!

I use radicale regularly and love it a lot. Thanks for all your efforts!

alex.

On 08/21/2015 06:46 PM, guillaume@kozea.fr wrote:
> Hello everyone,
> 
> Radicale 0.10 is a bit old, and it's time for another release. I'll 
> release
> this new version next week, and I've decided to call it 1.0, because:
> 
> - there are no big changes since 0.10 but some small changes are really 
> useful,
> - simple tests are now automatically launched on Travis, and more can be
>   added in the future (https://travis-ci.org/Kozea/Radicale).
> 
> This 1.0 version will be maintained with only simple bug fixes on a 
> separate
> git branch.
> 
> Once this milestone is reached, it's time to think about the future. 
> When
> Radicale has been created, it was just a proof-of-concept. The main 
> goal was
> to write a small, stupid and simple CalDAV server working with 
> Lightning, using
> no external libraries. That's how we created a piece of code that's 
> (quite)
> easy to understand, to use and to hack.
> 
> The first lines have been added to the SVN (!) repository as I was 
> drinking
> beers at the very end of 2008. It's now packaged for a growing number 
> of Linux
> distributions. And that was fun going from here to there thanks to you.
> 
> Things have changed, many users now rely on Radicale in production. For
> example, I use it to manage medical calendars, with thousands requests 
> per day.
> Many people are happy to install Radicale on their small home servers, 
> but are
> also frustrated by performance and unsupported specifications when 
> they're
> trying to use it seriously.
> 
> I think that Radicale 2.0 should:
> 
> - rely on a few external libraries for simple critical points (dealing 
> with
>   HTTP and iCal for example),
> - be thread-safe,
> - be small,
> - be documented in a different way (for example by splitting the client 
> part
>   from the server part, and by adding use cases),
> - let most of the "auth" modules outside in external modules,
> - have more and more tests,
> - have reliable and faster filesystem and database storage mechanisms,
> - get a new design :).
> 
> I'd also secretly love to drop the Python 2.x support.
> 
> These ideas are not all mine (except from the really, really, really 
> important
> "design" point :p), they have been proposed by many developers and 
> users.
> I've just tried to gather them and keep points that seem important to 
> me.
> 
> What do you think of that? I'm sure that you now want to:
> 
> - tell that issue #X or pull request #Y should be closed before 1.0,
> - discuss these points and add your owns,
> - propose your favorite libraries.
> 
> I'll be glad to read your mails!
> 

Re: [radicale] Radicale 1.0 is coming, what's next?

From:
Gary
Date:
2015-08-23 @ 00:20
Allow me to also add my thanks; great program. 

Gary

> On Aug 22, 2015, at 12:18 PM, alex. <thissideup@riseup.net> wrote:
> 
> I just want to say thank you very, very much!
> 
> I use radicale regularly and love it a lot. Thanks for all your efforts!
> 
> alex.
> 
>> On 08/21/2015 06:46 PM, guillaume@kozea.fr wrote:
>> Hello everyone,
>> 
>> Radicale 0.10 is a bit old, and it's time for another release. I'll 
>> release
>> this new version next week, and I've decided to call it 1.0, because:
>> 
>> - there are no big changes since 0.10 but some small changes are really 
>> useful,
>> - simple tests are now automatically launched on Travis, and more can be
>>  added in the future (https://travis-ci.org/Kozea/Radicale).
>> 
>> This 1.0 version will be maintained with only simple bug fixes on a 
>> separate
>> git branch.
>> 
>> Once this milestone is reached, it's time to think about the future. 
>> When
>> Radicale has been created, it was just a proof-of-concept. The main 
>> goal was
>> to write a small, stupid and simple CalDAV server working with 
>> Lightning, using
>> no external libraries. That's how we created a piece of code that's 
>> (quite)
>> easy to understand, to use and to hack.
>> 
>> The first lines have been added to the SVN (!) repository as I was 
>> drinking
>> beers at the very end of 2008. It's now packaged for a growing number 
>> of Linux
>> distributions. And that was fun going from here to there thanks to you.
>> 
>> Things have changed, many users now rely on Radicale in production. For
>> example, I use it to manage medical calendars, with thousands requests 
>> per day.
>> Many people are happy to install Radicale on their small home servers, 
>> but are
>> also frustrated by performance and unsupported specifications when 
>> they're
>> trying to use it seriously.
>> 
>> I think that Radicale 2.0 should:
>> 
>> - rely on a few external libraries for simple critical points (dealing 
>> with
>>  HTTP and iCal for example),
>> - be thread-safe,
>> - be small,
>> - be documented in a different way (for example by splitting the client 
>> part
>>  from the server part, and by adding use cases),
>> - let most of the "auth" modules outside in external modules,
>> - have more and more tests,
>> - have reliable and faster filesystem and database storage mechanisms,
>> - get a new design :).
>> 
>> I'd also secretly love to drop the Python 2.x support.
>> 
>> These ideas are not all mine (except from the really, really, really 
>> important
>> "design" point :p), they have been proposed by many developers and 
>> users.
>> I've just tried to gather them and keep points that seem important to 
>> me.
>> 
>> What do you think of that? I'm sure that you now want to:
>> 
>> - tell that issue #X or pull request #Y should be closed before 1.0,
>> - discuss these points and add your owns,
>> - propose your favorite libraries.
>> 
>> I'll be glad to read your mails!
>>