Re: [Gnu-arch-users] diary application with tla

[Brian May]

>>>>> "Tom" == Tom Lord <address@hidden> writes:

    Brian> With vpn/sftp, if somebody breaks into the server, they get
    Brian> to read access to everything.

    Tom> Ack.  Don't get me wrong, I'm warming up to the idea.  Not
    Tom> convinced yet, but considering.

    Tom> Someone should pay for it or do it themselves, really:
    Tom> Non-commercial FOSS projects mostly don't care about this
    Tom> kind of stuff while companies, _especially_ with such heavy
    Tom> emphasis on outsourcing these days, are the more likely to
    Tom> benefit.

The issue here seems to be what non-commercial projects require this
level of security?

Ok, I will bite ;-)

I have seriously considered the idea of using arch to represent a
diary. This would have the benefit over a conventional diary that you
keep a history of changes you have made, and why you have made
them. It would also make it easy to keep synchronised between
different computers, even if you make changes on them simultaneously
(just don't make conflicting changes...).

You could also have separate branches, eg. one for your public diary
for evens you want to publish online your website, and another one for
private entries. This may require more thought.

One way of doing implementing a diary with arch, for instance would be
to have a directory structure like this:

eg.

# View calendar entry for today at 12:00 to 14:00.
> cat calendar/2003/01/03/1200-1400-UTC+11
Write new diary application

# Reschedule it until tomorrow
> tla mv calendar/2003/01/03/1200-1400-UTC+11 
> calendar/2003/01/04/1200-1400-UTC+11

# Look at urgent job
> cat todo/urgent/job/xyz
Contact XYZ about ZZZ.

# Mark urgent job as done
> tla mv todo/urgent/job/xyz todo/done/job/xyz

# List all urgent job related tasks
> ls todo/urgent/job
[...]

# List all urgent tasks (probably not the best method, it will list
# .arch-ids directories)
> find todo/urgent
[...]

Obviously, a high level set of tools would be desired to display this
in a user friendly way. I haven't yet considered reoccurring
jobs. There are several ways these could be implemented.

I am not sure how well this would work (or what problems this might
cause), but you could even have cross references between, eg. calendar
entries and todo entries using the arch-id, that way the cross
reference remains accurate even if the entry is deleted or moved.

Anyway, such a project contains private data that people may want to
store encrypted, is non-commercial (although could also be used
commercially) and could be done entirely with FOSS software.

Just a thought.
-- 
Brian May <address@hidden>