Opencaching.de

Die Plattform opencaching.de => Entwicklung => Thema gestartet von: Slini11 am 17. Mai 2016, 02:37:39

Titel: occode vs cacheid in link
Beitrag von: Slini11 am 17. Mai 2016, 02:37:39
Aktuell ist der Status Quo im OC-Code, dass einige Links auf OC per OC-Code (https://www.opencaching.de/viewcache.php?wp=OC701D, auch möglich ist https://www.opencaching.de/OC701D) und andere per Cache-id (https://www.opencaching.de/viewcache.php?cacheid=131769) auf das Listing verweisen.

Nun meine Frage: Wie wollen wir das in Zukunft handhaben? Denn wenn man irgendwo gerade am Code schraubt, kann man das ja ggf. gleich mitumstellen.
Titel: Re: occode vs cacheid in link
Beitrag von: ClanFamily (Mirco) am 17. Mai 2016, 08:52:35
Hi, das ist nicht das Ziel.
wir werden durch PSR4 die Pfade anpassen und Router einsetzen.
Titel: Re: occode vs cacheid in link
Beitrag von: Hanekju am 17. Mai 2016, 08:58:55
In meinen Augen müssten alle Möglichkeiten, einen Cache aufzurufen, weiterbestehen, um tote Links (zum Beispiel in Blogs, sozialen Netzwerken oder ähnlichem) zu vermeiden.

Propagieren würde ich diese Variante:
https://www.opencaching.de/OC701D
Titel: Re: occode vs cacheid in link
Beitrag von: ClanFamily (Mirco) am 17. Mai 2016, 09:00:08
In meinen Augen müssten alle Möglichkeiten, einen Cache aufzurufen, weiterbestehen, um tote Links (zum Beispiel in Blogs, sozialen Netzwerken oder ähnlichem) zu vermeiden.

Propagieren würde ich diese Variante:
https://www.opencaching.de/OC701D

Deswegen "Routen" wir die alten Links natürlich... und die letzte Variante ist schon gern gesehen...
Titel: Re: occode vs cacheid in link
Beitrag von: following am 17. Mai 2016, 15:13:08
Besser: https://www.opencaching.de/geocache/OC701D

Cache-Codes können im Prinzip beliebig aussehen, auch wenn in der OC.de-Datenbank bislang nur das Format "OC<Hexzahl>" existiert; auf der "Hauptebene" könnte es dann Kollisionen mit anderen Seitennamen geben. Die Zwischenebene "geocache" vermeidet das.
Titel: Re: occode vs cacheid in link
Beitrag von: 4_Vs am 17. Mai 2016, 18:53:04
Besser: https://www.opencaching.de/geocache/OC701D

Cache-Codes können im Prinzip beliebig aussehen, auch wenn in der OC.de-Datenbank bislang nur das Format "OC<Hexzahl>" existiert; auf der "Hauptebene" könnte es dann Kollisionen mit anderen Seitennamen geben. Die Zwischenebene "geocache" vermeidet das.
Macht den Link aber auch länger :(
Titel: Re: occode vs cacheid in link
Beitrag von: ClanFamily (Mirco) am 18. Mai 2016, 19:21:31
Muss eigentlich gar nicht ;)

.de/OC015f8b funktioniert genau so wie .de/oc254ac5 oder .de/oc123456789abcde

Das regelt der Symfony Controller...
Titel: Re: occode vs cacheid in link
Beitrag von: following am 18. Mai 2016, 21:07:25
Was sagt der Symfony-Controller denn hierzu:

opencaching.ca/caches

Soll er da nun die Seite "Caches" anzeigen, oder den Geocache mit dem Code CACHES (CA + CHES) von Opencaching Kanada? Geht auch als

opencaching.de/caches

falls wir die OC-Seiten irgendwann mal vernetzen.  Alles kann ein Cache-Code sein, also wenn man die auf die oberste Ebene legt, dann kann man dort keine anderen Seiten mehr einblenden.
Titel: Re: occode vs cacheid in link
Beitrag von: ClanFamily (Mirco) am 18. Mai 2016, 22:04:36
wie wäre es dann künftig mit sowas hier:
...de/go/oc123456
Titel: Re: occode vs cacheid in link
Beitrag von: Bananeweizen am 18. Mai 2016, 22:27:50
Ihr könnt jetzt natürlich versuchen, eine neue längere kanonische URL einzuführen, die sicher frei von Kollisionen ist. Dann habt ihr aber jeden Tag kaputte Links, weil wieder jemand vergessen hat, ob er nun /geocache/ oder /cache/ oder /caches/ oder /go/ oder was auch immer in die URL schreiben muss. Oder ihr belasst es bei der für _Menschen_ ganz einfach zu merkenden Variante server.tld/occode und regelt die drei Ausnahmen, die tatsächlich zu Kollisionen führen, in der Serverkonfiguration oder sonstwo.

Anders gesagt: Ihr solltet die URL nicht für maschinelle Verarbeitung, sondern für die Nutzer der Webseite optimieren. Optimierte Lösungen sind nicht immer optimale Lösungen.

PS: Ich leide selbst unter diesem Syndrom des "als Programmierer optimieren wollens". Wenn ihr aber wirklich Benutzeranforderungen zu diesem Thema einfordern würdet (statt technikgetrieben zu argumentieren), wäre die längere URL ganz schnell vom Tisch. :)
Titel: Re: occode vs cacheid in link
Beitrag von: 4_Vs am 19. Mai 2016, 00:31:49
+1


Gesendet von iPhone mit Tapatalk
Titel: Re: occode vs cacheid in link
Beitrag von: following am 19. Mai 2016, 01:39:34
Dann habt ihr aber jeden Tag kaputte Links, weil wieder jemand vergessen hat, ob er nun /geocache/ oder /cache/ oder /caches/ oder /go/ oder was auch immer in die URL schreiben muss.

Hat geocaching.com jeden Tag kaputte Links wegen der URL-Form https://www.geocaching.com/geocache/GC1X9PE?

Wenn man es von Hand schreibt ist eh das hier am einfachsten (ohne www.):

opencaching.de/OCxxxx
opencaching.de/ocxxxx

Das stört nicht, wie gehabt als Weiterleitung nach www.opencaching.de/...

Zitat
regelt die drei Ausnahmen, die tatsächlich zu Kollisionen führen, in der Serverkonfiguration oder sonstwo.

Nicht drei Ausnahmen, sondern zu 100% überlappende Namensräume. Jede beliebige Folge aus den Zeichen a-z und/oder A-Z und/oder 0-9 kann irgendwann mit einem Cache-Code kollidieren.

Wenn man das jetzt kurzsichtigerweise in einem Namensraum zusammenwirft, kann daran irgendwann die Teilnahme an einem Opencaching-Netzwerk oder der Umstieg anderer Opencaching-Seiten auf den deutschen Code scheitern - oder man muss es dann wieder umbauen und zerstört damit bestehende externen Links auf OC-Caches.
Titel: Re: occode vs cacheid in link
Beitrag von: ClanFamily (Mirco) am 22. Mai 2016, 12:02:24
Haben die anderen Knotenpunkte nich ein eigenes Prefix.  ... das sollte doch dann kein Problem werden.

Gesendet von meinem SM-G800F mit Tapatalk

Titel: Re: occode vs cacheid in link
Beitrag von: following am 22. Mai 2016, 13:34:50
Haben die anderen Knotenpunkte nich ein eigenes Prefix.  ... das sollte doch dann kein Problem werden.

Wir können nicht vorhersehen, welche Opencaching-Seiten in Zukunft noch entstehen werden und welchen Prefix die wählen. Der muss nicht mit "O" beginnen.

Hinzu kommen sämtliche anderen bestehenden und zukünftigen Geocaching-Seiten mit Doppellistings, wenn wir diese wie gehabt über den Fremdcode abrufbar machen wollen:

http://opencaching.de/gchane

Man würde also das Risiko eingehen, dass in Zukunft
Wollen wir dieses Risiko eingehen?
Titel: Re: occode vs cacheid in link
Beitrag von: Bananeweizen am 23. November 2016, 18:55:54
Wollen wir dieses Risiko eingehen?
Ja. Das ist ein theoretisches Risiko. Ich halte es für um Größenordnungen wahrscheinlicher, dass vorher
* der gesamte Code von Opencaching.de zum n-ten Mal neu geschrieben worden ist und schon deswegen das Problem nicht mehr besteht
* Opencaching.de nicht mehr existiert
* Webseiten nicht mehr per URL aufgerufen werden
* oder Donald Trump dafür gesorgt hat, dass es kein Geocaching mehr gibt.

Bei uns im Projekt würde ich jetzt sagen: Die Vorteile überwiegen das Risiko bei weitem, deshalb einfach machen. Das Problem lösen wir dann, wenn es eintritt. :)
Titel: Re: occode vs cacheid in link
Beitrag von: bohrsty am 24. November 2016, 11:09:06
ich stelle mal eine "provokative" alternative vor: was ist mit einem eigenen url-shortener wie "go oc", denn die domain "go-oc.de" ist noch zu haben (oder generisch: go-oc.org, die ist auch noch zu haben)...
ja, ich weiss, dass stellt auch alle links um, aber (und das gilt auch fuer alle anderen alternativen) wenn wir uns jetzt entscheiden die oc-urls "neu" zu machen und alle anderen (alten) moeglichkeiten solange ueber die router bestehen lassen, bis es evtl. eine technische oder entwicklungsnotwendigkeit gibt sie zu aendern, bleibt genug zeit sich an die neue url zu gewoehnen... und danach fuehren diese urls ja auch nichts ins leere, sondern auf die seiten, fuer die die aenderung notwendig wurde... und da gibt es bestimmt technische moeglichkeiten (z.b. anhand des referrers) heraus zu finden, von wo eine url aufgerufen wurde und einen entsprechenden hinweis an zu zeigen...

...und ja, natuerlich wuerde ich die domain auch sponsoren...
Titel: Re: occode vs cacheid in link
Beitrag von: 4_Vs am 24. November 2016, 11:36:09
Dafür


Gesendet von iPhone mit Tapatalk
Titel: Re: occode vs cacheid in link
Beitrag von: ClanFamily (Mirco) am 24. November 2016, 13:07:46
Klingt gut. hat G$ auch in form von coord.info/
Können wir auf jedenfall einsetzen.
In Anbetracht der Internationalen Verwendung wäre die .org als primäre Umleitung denkbar.
Die .de als "Backup" für jene, die es nicht behalten.... mit selber Funktion.
Titel: Re: occode vs cacheid in link
Beitrag von: Slini11 am 24. November 2016, 13:19:16
Als Anmerkung:
Es gibt schon die short-Domain http://2oc.de/ (Inhaber ist flopp)
Titel: Re: occode vs cacheid in link
Beitrag von: mic@ am 29. November 2016, 08:46:26
Zitat von: ClanFamily (Mirco)
Klingt gut. hat G$ auch in form von coord.info

Und das Gleiche gibt es auch als coord.ch , wobei hier auch OC-Codes akzeptiert werden  ;)
Zum Beispiel http://coord.ch/OC10356
Titel: Re: occode vs cacheid in link
Beitrag von: mirabilos am 08. Januar 2017, 23:40:27
Direkt OCxxxxx in der URI mit festem Schema würde es Betreibern von Weiterleitern (wie mit http://www.mirbsd.org/cvs.cgi/www/files/wp.cgi?rev=HEAD mir zB ☺) erleichtern, mit möglichst wenig Redirections auf HTTP-Ebene (= weniger round trips = schnellerer page load, weniger traffic) ans Ziel zu kommen.
Titel: Re: occode vs cacheid in link
Beitrag von: Bananeweizen am 09. Januar 2017, 21:29:01
Gefiele mir auch sehr. Ziel der ganzen Diskussion war ja, für _Menschen_ das Verlinken zu erleichtern, und das wäre damit definitiv erreicht.
Titel: Re: occode vs cacheid in link
Beitrag von: ScoutCacher am 29. Januar 2017, 12:32:08
Wenn ich auch noch einen Gedanken in die Diskussion einschmeißen darf. Ob's hier passend ist oder ein seperater Thread sein sollte?

Ich kopiere mir ganz gerne, wenn ich ein Tour zusammenstelle, von den Caches in sowas wie OO Calc, die URLs zusammen.
Sicher gibt es bessere Methoden, um zu planen, haben sich halt bei mir noch nicht vorgestellt ;)

Aber dazu  ist es fein, wenn z.b. der Kartenlink als shortURL und z.b. _Cachename in der Adresszeile des Browsers erscheint.
Dann ist ein kopieren derselben und zerteilen in cnamec und nummer ganz einfach. Im Moment kopier ich halt den CacheNamen und muss den dann als (unformartierten Text) einfügen.
Natürlich sollte es NICHT notwendig sein beim einem Link, den Cachename angeben zu müssen - OCCode sollte reichen. Siehe diese Diskussion,den Cache mit ShortURL aufrufen. Wäre nur fein (für mich ;) als Feature den Namen noch im z.B. Kartenlink mit dabei zu haben.
Im Bootmarkmanager vom Browser (alle?) wird ja der Seitentitel als Titel verwendet und die URL verlinkt, da reicht es für die Übersicht, das die Seite den richtigen Titel hat (hat sie ja).

Ich hoff, das ist nicht ganz offtopic,
danke,
Andi