FeD Diskussion:Projekte/Kalenderformat

09:56 <@pieta> könnte man da nicht was machen mit einer-datei-pro-eintrag? ok, wäre natürlich ein neues format, aber wenn iCal son murks ist...
09:56 <@pieta> wäre aber sehr einfach zu synchonisieren, z.b. mit rsync
10:16 <@riot> und was ist, wenn sich ein eintrag ändert?
10:18 <@pieta> dann wird die neuere datei übertragen...glaub mir, dass kann rsync ;-)
10:18 <@pieta> -s
10:33 <@riot> pieta: rsync.. ja
11:22 <@pieta> also ich finde ein format, dass rsync sychronisieren kann, ausgesprochen praktisch. einmal zu backup-zwecken, aber andererseit bedeutet das, dass die synchornisierung so einfach ist, dass das
               jeder andere auch kann
11:23 <@pieta> und ein konverter neu->iCal stelle ich mir auch nicht so schwer vor
12:16 <@airmack> pieta: wenn du dir darüber gedanken machst, kannst du die ja mal kurz in einem paper festhalten
12:16 < evilop> :D
12:16 <@airmack> hört sich so ein bischen wie mbox -> maildir an
12:17 <@airmack> müßte man sich aber gedanken machen, wie man die ganzen daten bennent und wie man diese auch ausseinander halten kann , bzw gleiche identifizieren
12:38 <@pieta> ich werde mal eine BuK (Bitte um Kommentare) in wiki machen
12:41 <@pieta> und ja, maildir (oder so, claws-mail verwendet da was ähnliches) war die idee dahinter
12:46 <@pieta> ah, claws verwendet das MH format
12:52 <@airmack> also ich inde das eigentlich auch angenehmer und stabiler die ganzen einträge in einem verzeichnis und nicht in einer datei zu haben
12:52 <@airmack> da ist generell der datenverlust, wenn man eine datei kaputt macht kleiner
12:52 <@airmack> gegen ein rm * hilft das natürlich auch nciht ;)
12:53 <@pieta> dagegen hilft nichts
12:53 <@pieta> aber eine schwierigkeit ist mir gerade eingefallen: wie unterscheidet man gelöschte einträge von noch nicht vorhandenen?
12:53 <@pieta> zwei ideen:
12:54 <@pieta> 1: datei da lassen, aber leer machen
12:54 <@airmack> doch ein alias z.B. alias rm='rm -i'
12:54 <@pieta> 2: datei mit inhalt da lassen, aber als gelöscht markieren
12:54 <@airmack> pieta: einfach einen .Trash aufmachen
12:54 <@airmack> für gelöschte termine
12:54 <@airmack> die dann extra gelöscht werden müssen
12:54 <@airmack> daher diese tauchen nicht mehr im Kalender auf
12:55 <@airmack> aber werden bei der syncro mitgenommen
12:55 <@airmack> oder ein prefix wie OLD DELETED
12:55 <@pieta> problem ist: eigentlich kannst du den trash nie löschen, da du nie sicher sein kannst, dass da nicht noch ein ungesyncter user unterwegs ist
12:55 <@airmack> also eher 2. Methode
12:57 <@pieta> aber das problem sollten alle kalenderformate haben, daher ist das wohl ok, wenn wir das problem auch haben
12:57 <@airmack> dann könnten wir aber auch die alten formate übernehmen ...
12:57 <@pieta> das ist ja nicht das einzige problem, dass wir lösen wollen
12:58 <@airmack> und die markierten einträge kann man spätestens löschen, wenn diese nicht mehr aktuell sind
12:58 <@airmack> also abgelaufen
12:58 <@pieta> also vorausgesetzt, ICal ist wirklich murks. wenn nicht, können wir den aufwand auch lassen
12:58 <@airmack> für iCal gibt es auch ein RFC
12:59 <@pieta> wäre denkbar, aber das wäre dann ein format ohne history.
13:00 <@pieta> also jedenfalls ohne history für gelöschte termine. ungelöschte aber abgelaufene bleiben erhalten
13:01 <@pieta> heißt allerdings, dass man auch keine termine in der vergangenheit anlegen kann
13:01 <@airmack> pieta also ich meine wenn das flag gelöscht gesetzt wurde und der termin abgelaufen ist
13:01 <@airmack> daher beides muss zutreffen
13:03 <@pieta> diese termine wirst du aber bein nächsten syncen wieder bekommen
13:04 <@airmack> hmm
13:04 <@airmack> da hast du recht
13:04 <@airmack> also müßte man die beiträge bis in alle ewigkeiten mitschleppen
13:04 <@airmack> s/beiträge/einträge
13:05 <@pieta> jou
13:05 <@airmack> nervt
13:05 <@airmack> und führt zur vermüllung
13:05 <@pieta> aber wie gesagt, da fällt mir gerade nichts gegen ein. das sollte bei allen formaten passieren
13:06 <@pieta> hm, wie macht IMAP das?
13:06 <@airmack> trash
13:07 <@airmack> du hast einmal eine lokale copy und eine auf dem server
13:07 <@airmack> und du wirst ja nie in die verlegenheit geraten deine lokale kopie hochladen zu wollen ;)
13:08 <@airmack> sondern du holst dir immer die neueste version vom server
13:08 <@airmack> das wäre natürlich auch eine variante, das ganze server based zu machen
13:08 <@airmack> daher nur der server hat die aktuelle version
13:08 <@airmack> und verteilt diese
13:08 <@pieta> hm, dachte ich mir
13:08 <@airmack> und du ziehst dir beim syncen immer die neueste version
13:09 <@pieta> ist aber nicht schön, ich will das verteilt haben, so wie DCVS: ich kann syncen von wem ich will
13:09 <@airmack> das würde aber auch heissen, das man keine lokalen einträge hochladen könnte
13:09 <@airmack> bzw die einträge die man im pda gemacht hat
13:10 <@pieta> man kann bei IMAP hochladen (stand in den letzten monaten in der c't: mails umziehen)
13:10 <@airmack> pieta: schiebst du den log hoch in die diskussion?
13:10 <@pieta> kann ich machen
13:10 <@airmack> ja hochladen schon
13:16 <@pieta> hm, irgendwie fällt mir keine dezentrale version ohne lösch-logbuch/deleted-tag/o.ä. ein
13:16 <@pieta> zentralisiert ist einfacher: der server hat immer recht
13:17 <@airmack> jo
13:17 <@airmack> ist aber eigentlich unpraktisch, da man auch unterwegs einträge macht
13:18 <@pieta> das ist ja kein problem, solange du deinen portable client danach syncst
13:18 <@pieta> zentralisiert bedeutet: alles clients syncen mit dem gleicher server
13:18 <@pieta> kein client-client-syncen
13:18 <@airmack> aso
13:18 <@airmack> jo
13:19 <@pieta> eigentlich möchte ich aber client-client syncen
13:19 <@airmack> könnte aber auch noch probleme geben
13:19 <@airmack> oder du machst auch noch ein revision system
13:19 <@airmack> daher es wird gespeichert werlche veriosn di e letzte ist
13:19 <@pieta> genauer will ich gar keinen server, halt so wie DVCS (git, hg, whatever)
13:19 <@airmack> mit der gesynct wurde
13:20 <@airmack> daher es wird ein forced sync vom server zum client gemacht bevor dieser updaten darf
13:20 <@airmack> wenn die version unterschiedlich sind
13:21 <@airmack> dabei wird aber versucht den alte datenbestand beizubehalten
13:21 <@pieta> dann braucht man auch noch eine art mergen...urgs
13:22 <@pieta> frei nach: du hast eine änderung und der server hat eine. wer hat nun recht?
13:25 <@airmack> nee das kannst du ja im anschließenden sync machen
13:25 <@airmack> ausser es handelt sich um die selbe veränderte datei
13:25 <@pieta> eben, das meine ich doch
13:25 <@airmack> dann schaut man einfach nach dem timestamp
13:25 <@pieta> szenario:
13:25 <@airmack> timestamp von erstellen des eintrages
13:26 <@airmack> s/von/vom
13:27 <@pieta> B und C ziehen beide von A. dann ändern B und C beide den gleichen Termin. dann synced B: alles OK. dann synced C und findet eine neue version, hat aber selber auch ein update. und nun?
13:27 <@airmack> timestamp
13:27 <@pieta> genaus das szenario, bei dem bei einer VCS dann gemergt wird
13:27 <@airmack> der jüngste timestamp hat recht
13:27 <@pieta> igitt
13:28 <@airmack> survival of the youngest
13:29 <@airmack> wieso will man eine alte version haben, wenn man schon eine neue persönlich später geändert hat?
13:29 <@pieta> ich würde eine nutzer-interaktion anfordern in dem moment: hier ist version A, hier ist B, welche soll ich nehmen? oder möchten sie vielleicht eine version C aus A und B machen?
13:29 <@airmack> da muss man schon selber einen fuck up gemacht haben
13:29 <@airmack> kann man sicherlich machen
13:29 <@airmack> mit dem standart der übernahme des jüngsten timestamp
13:30 <@pieta> jou, frei nach: hauen sie auf enter um die jüngste verion zu bekommen
13:30 <@airmack> jopp
13:32 <@pieta> oder man macht wirklich ein merge: benutzer-interaktion nur dann, wenn änderungen konflikte bringen (beide parteien haben z.b. den ort geändert)