Thanks everyone for the input. It looks like B is the clear winner. We'll offer Export only for 1.5 and target the thornier import problem to 2.0.
If anyone wants to volunteer to cleanup the UI to reflect this, come forward, otherwise I'll take care of it soon. Cheers, Luke On Nov 7, 2007, at 12:55 PM, Simon Rozet wrote: > On 11/6/07, Luke Melia <[EMAIL PROTECTED]> wrote: >> Hi Tracks folks, >> >> The current status of the import/export features in the trunk is >> this: >> >> Export to YAML, XML, & CSV is implemented. >> Import is not implemented. >> Versioning has not been considered (AFAIK) >> >> So, in order to move speedily to a 1.5 release, we need to consider >> how this feature should ship. Our options, for your input: >> >> A) Remove "Import/Export" from the UI. >> B) Rename "Import/Export" to "Export" and adjust language >> accordingly. >> C) Someone volunteers to implement Import and come up with a plan for >> dealing with versioning of data as Tracks evolves. >> >> Thoughts? > > What a coincidence! I've started to think about how I may implement > sync between my little command line GTD apps and Tracks. > AFAIK, Tracks expose its data through a RESTFul interface so it is > easily accessible with ActiveResource. But sadly it isn't as easy as I > first thought. > > Anyway from the user's point of view the import/export capabilities is > a great feature. Being able to easily switch to another Tracks > provider would be awesome > But on the implementor's point, this isn't easy. As you've said > before, what if the schema change? So I think we should indicate > what's the schema version in the dump so the importer can convert it > if necessary. > > On the other hand, it'd great to make a new release ASAP so I think B > is the better solution ATM. > > My two cents > > -- > Simon Rozet <[EMAIL PROTECTED]> _______________________________________________ Tracks-discuss mailing list [email protected] http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
