Re: GNUstep Objective-C based CalDAV server

[Ivan Vučica]

On 26.10.2013. 18:26, Doc O'Leary wrote:
> In article <mailman.4734.1382728381.10748.discuss-gnustep@gnu.org>,
>  Ivan Vuãica <ivan@vucica.net> wrote:
>
>> On Fri, Oct 25, 2013 at 5:44 PM, Doc O'Leary <
>> droleary@6usenet2013.subsume.com> wrote:
>>
>>> I think you're looking at the wrong problem.  It's mainly an issue of
>>>  getting some objects you have coerced into the iCalendar format.  I do
>>> this, for example, with calendaRSS:
>>>
>>> http://cal.subsume.com/
>>>
>>> No special server needed.  The current server version uses Ruby, but the
>>> original version from 2002 used ObjC.  I could send you the class file,
>>> but it was simple enough for my special case of RSS feeds that I hard
>>> coded a lot of it.
>>>
>> Are you sure Andreas doesn't need changes made inside the iOS calendar to
>> propagate back into their application?
> I not sure of anything.  :-)  Using calendars for database input, 
> though, seems quite convoluted.
...wait, it sounds more convoluted than reading RSS through calendar?
:-) :-)
>   If I had to do that for some reason, I 
> wouldn't set out to write CalDAV server in ObjC.  I would instead use an 
> existing server and just find a hook to run ObjC code (or any language, 
> really) when changes are made to calendars/events.
The database sounds like it specifically stores calendars et al, and it
sounds like Andreas' goal is to provide another way to access it.

I personally think that direct access to data, especially when you
control the schema, is easier to handle than synchronizing or hooking
into existing servers. Something like SabreDAV is as close as I would
get in Andreas' described situation: a framework that provides WebDAV
and CalDAV API functionality while actually querying developer's classes
for information to provide to the end user.

And if you want to be specific, something like SabreDAV could be
interpreted not as a framework, but as a server that developer is just
hooking into.
>
>> CalDAV allows that, unlike a read-only stream provided in an .ics over HTTP.
> True enough.  Keep in mind, too, that whatever way is chosen, input from 
> the calendar still requires parsing the iCalendar format and/or writing 
> to an API that has done the parsing (e.g., Apple's EventKit).  It's not 
> particularly complicated, but it is non-standard enough that it'll 
> likely require more work than just using a common RESTful API using XML 
> or JSON.
Oh, certainly. That's the "interesting" part of this particular idea,
isn't it?