Re: Re: Changing default file type for user tasks from ics to xml

Hi Tor,

Tor Norbye wrote:

> Now it has been added back... although I don't know if it's xcal or  
> some netbeans-specific dtd. 

It's NB-specific

>>> - We do not support the whole ics standard and once
>>>     opened all unknown ics fields are stripped
>>
>
> That's not supposed to be the case! I haven't looked at this code in 
> a  long time, but at least once upon a time, the icalendar importer 
> stored  all the unrecognized fields in a list, and when writing the 
> list back,  simply wrote the unrecognized fields back too!  This is 
> part of the  work Trond did. 

You're right! Although I commited my last change a week ago you know 
some parts of the code better.
The fields are really preserved but moved to the end of a task during 
the export.

>
>
>>> - There are many features in user tasks (especially subtasks)
>>>     that are not supported by ics and we have to use
>>>     NB-specific fields
>>
>
> Really? There's the RELATED-TO field which seems to be used precisely  
> for this. Unlike XML, subtasks are not treated by "containment",  
> instead, a subtask simply references another id as its parent, so 
> when  parsing we have to go and build up the tree using these. (When 
> you  define the children before the parent this requires some book 
> keeping  :(
>
> This does however have the nice advantage that ics files are "flat", 
> so  they behave better under version control. 

XML files are not worse for CVS than ICS IMHO.

>
>
> My "hope" at one point had been that the tasklist module could simply  
> "re-use" your existing calendar files. In fact, one of my "favorite"  
> features at one point would be to implement remote calendar support.  
> There's an RFC for this, and I think it's referenced from the  
> "documents" page on the tasklist web site.   The idea would be that 
> you  have a calendar server - which you already access with evolution 
> or  icalendar or whatever. Then tasklist would connect to the same 
> server -  list your tasks just the way evolution's todo list does it, 
> and editing  it would update the calendar server.  Since I access my 
> calendar from  multiple sites and computers, this would be a big win, 
> since I wouldn't  have to drag my tasklists around with me on my 
> laptop.  There's a  protocol for how this is managed, similar to imap 
> - you'd have some  code such that in offline mode if you've added or 
> deleted tasks, they  get synced to/from the server next time you connect.

Sorry, but it's not important for me and i'm not going to implement it. 
At least in the near future.

>
> The reason I didn't get far on this - besides getting even more 
> excited  about implementing suggestions and forgetting all about the 
> usertasks  module - is that I couldn't find a -server- ! It appears 
> the open  source community have many, many good calendar client 
> applications -  but no good servers! I've heard Kollab is supposed to 
> address this by  writing an exchange-like server - so perhaps this 
> will be addressed  soon. But this seems to me to be a really really 
> good idea for a  project - implement a RFC-compliant calendar server 
> in java! Java is  great for implementing servers - look at Jakarta.
>
> Wow, talk about digressing! Sorry.
>
> Anyway, hope that provides some interesting background, and if it  
> wasn't clear, I really hope the icalendar support won't suffer :)  I  
> think it would be ideal if the default file format was user 
> selectable.   I think it used to be that way (before we stripped out 
> the xcal  support) : we used to have (we may still have it?) an option 
> which  specifies the "default" tasklist - the one which is opened if 
> you just  click on the user tasks window button (or new task) - as 
> opposed to  opening a calendar file in the filesystem explorer. The 
> filename  extension determined which format the file was written in -  
> {userdir}/tasklist.xcal or {userdir}/tasklist.ics.
>
> Wait - I think the filename extension may have been "xcs", nor 
> "xcal".  Things are starting to come back to me....
>
> -- Tor


--Tim