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

On Jan 30, 2004, at 1:38 AM, Petr Kuzel wrote:

> Tim Lebedkov wrote:
>
>> Hi,
>>
>> I plan to change the default file type for user entered tasks
>> from ics to xml (see the DTD here
>> http://tasklist.netbeans.org/source/browse/tasklist/usertasks/src/ 
>> org/netbeans/modules/tasklist/usertasks/translators/usertasks 
>> -1_0.dtd?rev=1.1&content-type=text/x-cvsweb-markup).
>>
>> The main reasons for this are:
>> - We do not support the whole ics standard and once
>>     opened all unknown ics fields are stripped
>> - XML format is better for auto generating HTML
>>     during a build (Ant + XSL)

Just a historical note - when I first wrote the user tasks module, I  
-did- use an xml format! When I announced the tasklist module  
contribution, somebody pointed me to a DTD on the internet for storing  
tasks - e.g. ical over xml - I think it was called "xcal" but I could  
be wrong. It's the "next great thing". So I was looking for existing  
xml files from these other tools to test my parser with - and couldn't  
find -any-. I tried all the open source calendar programs (various  
gnome ones, various kde ones), and also googled for calendars sitting  
around.  But I discovered that -everybody- are still using .ics.   Even  
the calendar app in OSX, which is very nice, uses ics. So the xml  
version hasn't really taken off - yet.

So I switched the default over to .ics.

Trond then did some more work on the icalendar import/export. We  
decided that keeping TWO import/export filters meant a lot of extra  
work (when nobody was using the xml file format anyway) so we deleted  
it!

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

>> - 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.

>> - 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.

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.

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

>
> Still ics dominates in real world so you need to keep import
> export. I suggest to carefully design xml indentation (and
> attribute ordering) to simplify file sharing (and merging)
> using version control systems. I could be big plus.
>
>   Good idea
>   Cc.
>
> PS: Have you any programming experience with calendaring servers.
> It could be the next step.
>
> -- 
> <address>
> <a href="mailto:[email protected]">Petr Kuzel</a> at Sun Microsystems :
> <a href="http://www.netbeans.org/">NetBeans Java IDE</a></address>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>