I want a key: Unterschied zwischen den Versionen

Wechseln zu: Navigation, Suche
(Die Seite wurde neu angelegt: „{{Projekt |kontakt = Jason |status = aktiv |beschreibung = Auf einheitliche und einfache Weise alle Schlüsselträger erreichen |interessenten = |status = akti…“)
 
K
 
(16 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 
{{Projekt
 
{{Projekt
 
|kontakt = Jason
 
|kontakt = Jason
−
|status = aktiv
+
|status = angekuendigt
 
|beschreibung = Auf einheitliche und einfache Weise alle Schlüsselträger erreichen
 
|beschreibung = Auf einheitliche und einfache Weise alle Schlüsselträger erreichen
 
|interessenten =
 
|interessenten =
−
|status = aktiv
 
 
}}
 
}}
  
Zeile 17: Zeile 16:
 
== Core ==
 
== Core ==
  
 +
Ablauf:
  
 +
* P1 sendet Anfrage ("möchte gerade ins Labor, wer kann mir einen Schlüssel leihen?")
 +
* Anfrage wird an alle (kostenlosen) Clients P2,...,Pn versendet
 +
** Fall1: P2 sendet positive Antwort ("Ja klar, fahre gerade selber hin"), Anfrage beendet.
 +
** Fall2: (optional) P2 sendet negative Antwort ("ich kann leider nicht"), Anfrage bleibt offen
 +
** Fall3: Timeout für kostenlose Clients, Kosten verursachende Clients werden benachrichtigt (SMS Dienst).
 +
** Fall4: weiterer Timeout: Anfrage wird erneut an alle Clients versendet, Wiederholung bis positive Antwort oder konfigurierte Obergrenze.
 +
** Fall5: P1 gibt auf, beendet Anfrage
 +
** Fall6: (optional) Alle aktuell angemeldeten Clients haben negative Antwort gesendet, Anfrage wird beendet.
 +
* Clients können sich an- und abmelden
 +
* Auch Antworten können wiederum beantwortet werden, dadurch entsteht keine neue Anfrage, sondern die Antwort geht direkt an den vorherigen Autor (oder an alle). Diese Funktion sollte nicht für kostenpflichtige Clients möglich sein (dann Fehlermeldung an Absender?)
 +
 +
* Gamification: Schnelles (positives) Antworten gibt Bonuspunkte (für irgendwas anderes)
  
 
== API ==
 
== API ==
  
−
Rest? Thrift?
+
<s>Rest?</s> Thrift?
  
 
{{API-Methode
 
{{API-Methode
 
|name= sendRequest
 
|name= sendRequest
 
|beschreibung=Sendet eine Anfrage mit einem Text
 
|beschreibung=Sendet eine Anfrage mit einem Text
−
|param1=String, text
+
|param1=text, String
−
|return1=long, messageId, die Id dieser Nachricht
+
|return1=messageId, Long, die Id dieser Nachricht
 
}}
 
}}
  
Zeile 33: Zeile 45:
 
|name= sendReply
 
|name= sendReply
 
|beschreibung=Beantwortet eine Anfrage mit einem Text
 
|beschreibung=Beantwortet eine Anfrage mit einem Text
−
|param1=long, messageId, Info welche Nachricht beantwortet wird.
+
|param1=messageId, Long, Info welche Nachricht beantwortet wird.
−
|param2=String, text, die Antwort
+
|param2=text, String, die Antwort
−
|param3=boolean, resolved, (optional?) Marker ob  
+
|param3=resolved, Boolean, (optional?) Marker ob der Schlüssel übergeben wird (true=Anfrage gelöst; false="Sorry, kann leider nicht")
−
|return1=long, messageId, die messageId dieser Nachricht
+
|return1=messageId, Long, die messageId dieser Nachricht
 
}}
 
}}
  
Zeile 42: Zeile 54:
 
|name= subscribe
 
|name= subscribe
 
|beschreibung=meldet einen Client an
 
|beschreibung=meldet einen Client an
−
|param1=String, clientIdentifier,  
+
|param1=clientIdentifier, String,
−
|param2=String, userString, Freitext für den Benutzer
+
|param2=userString, String, Freitext für den Benutzer
−
|return1=long, clientId, die Id für den Client
+
|return1=clientId, Long, die Id für den Client
 
}}
 
}}
  
 
{{API-Methode
 
{{API-Methode
 
|name= unsubscribe
 
|name= unsubscribe
−
|beschreibung=meldet einen Client an
+
|beschreibung=meldet einen Client ab
−
|param1=String, clientIdentifier,
+
|param1=clientId, Long, die Id für den Client
−
|param2=String, userString, Freitext für den Benutzer
 
−
|return1=long, clientId, die Id für den Client
 
 
}}
 
}}
−
 
−
 
  
 
== Clients ==
 
== Clients ==
Zeile 68: Zeile 76:
 
* SMS-Gateway benötigt (kostenpflichtig?)
 
* SMS-Gateway benötigt (kostenpflichtig?)
 
* Zeitverzögert?
 
* Zeitverzögert?
−
** Kosten vermeiden, wenn jemand anderes  
+
** Kosten vermeiden, wenn jemand anderes vor Ablauf einer Wartezeit bereits positiv antwortet
 +
* Sehr wichtig, da einige Schlüsselträger nur über SMS erreichbar sind
  
 
=== IRC ===
 
=== IRC ===
  
−
sollte über den vorhandenen Bot relativ leicht zu adaptieren sein
+
* sollte über den vorhandenen Bot relativ leicht zu adaptieren sein
 +
* Im offenen Kanal oder einzeln die Benutzer ansprechen?
  
 
=== Weitere/Ideen ===
 
=== Weitere/Ideen ===
Zeile 78: Zeile 88:
 
* Twitter-DM?
 
* Twitter-DM?
 
* Jabber?
 
* Jabber?
 +
 +
== Alternative Lösungen ==
 +
* https://stratum0.org/wiki/StratumKey Automatisches schlüsselloses Schließsystem
 +
** Wird leider (derzeit) im Labor nicht umsetzbar sein (Stand 4/2015, was ist die Begründung?)
 +
*** Wir haben derzeit keine Möglichkeit die innere Tür im Foyer anders als mit der RFID-Karte vom TZH zu öffnen. --[[Benutzer:Trublu|Trublu]] ([[Benutzer Diskussion:Trublu|Diskussion]]) 13:52, 21. Apr. 2015 (CEST)

Aktuelle Version vom 27. April 2015, 17:17 Uhr

I want a key
Beschreibung: Auf einheitliche und einfache Weise alle Schlüsselträger erreichen
Kontakt: Jason
Status: angekündigt (Was heißt das?)

IWAK - I want a key' soll ein System werden um einfach und effizient alle zu erreichen, die aktuell einen Schlüssel zum Freien Labor haben.

Anforderungen

  • möglichst viele Client-Anwendungen unterstützen (Messenger, IRC, SMS, ...)
  • Einfache Bedienung, nur einmal handeln um alle möglichst schnell zu erreichen.
  • Rückkanal von jedem Client zum Anfragenden ermöglichen

Core

Ablauf:

  • P1 sendet Anfrage ("möchte gerade ins Labor, wer kann mir einen Schlüssel leihen?")
  • Anfrage wird an alle (kostenlosen) Clients P2,...,Pn versendet
    • Fall1: P2 sendet positive Antwort ("Ja klar, fahre gerade selber hin"), Anfrage beendet.
    • Fall2: (optional) P2 sendet negative Antwort ("ich kann leider nicht"), Anfrage bleibt offen
    • Fall3: Timeout für kostenlose Clients, Kosten verursachende Clients werden benachrichtigt (SMS Dienst).
    • Fall4: weiterer Timeout: Anfrage wird erneut an alle Clients versendet, Wiederholung bis positive Antwort oder konfigurierte Obergrenze.
    • Fall5: P1 gibt auf, beendet Anfrage
    • Fall6: (optional) Alle aktuell angemeldeten Clients haben negative Antwort gesendet, Anfrage wird beendet.
  • Clients können sich an- und abmelden
  • Auch Antworten können wiederum beantwortet werden, dadurch entsteht keine neue Anfrage, sondern die Antwort geht direkt an den vorherigen Autor (oder an alle). Diese Funktion sollte nicht für kostenpflichtige Clients möglich sein (dann Fehlermeldung an Absender?)
  • Gamification: Schnelles (positives) Antworten gibt Bonuspunkte (für irgendwas anderes)

API

Rest? Thrift?


sendRequest

Sendet eine Anfrage mit einem Text

Parameter: NameTypBeschreibung
text String
Rückgabewerte: NameTypBeschreibung
messageId Long die Id dieser Nachricht


sendReply

Beantwortet eine Anfrage mit einem Text

Parameter: NameTypBeschreibung
messageId Long Info welche Nachricht beantwortet wird.
text String die Antwort
resolved Boolean (optional?) Marker ob der Schlüssel übergeben wird (true=Anfrage gelöst; false="Sorry
Rückgabewerte: NameTypBeschreibung
messageId Long die messageId dieser Nachricht


subscribe

meldet einen Client an

Parameter: NameTypBeschreibung
clientIdentifier String
userString String Freitext für den Benutzer
Rückgabewerte: NameTypBeschreibung
clientId Long die Id für den Client


unsubscribe

meldet einen Client ab

Parameter: NameTypBeschreibung
clientId Long die Id für den Client


Clients

Telegram

SMS

  • SMS-Gateway benötigt (kostenpflichtig?)
  • Zeitverzögert?
    • Kosten vermeiden, wenn jemand anderes vor Ablauf einer Wartezeit bereits positiv antwortet
  • Sehr wichtig, da einige Schlüsselträger nur über SMS erreichbar sind

IRC

  • sollte über den vorhandenen Bot relativ leicht zu adaptieren sein
  • Im offenen Kanal oder einzeln die Benutzer ansprechen?

Weitere/Ideen

  • Twitter-DM?
  • Jabber?

Alternative Lösungen

  • https://stratum0.org/wiki/StratumKey Automatisches schlüsselloses Schließsystem
    • Wird leider (derzeit) im Labor nicht umsetzbar sein (Stand 4/2015, was ist die Begründung?)
      • Wir haben derzeit keine Möglichkeit die innere Tür im Foyer anders als mit der RFID-Karte vom TZH zu öffnen. --Trublu (Diskussion) 13:52, 21. Apr. 2015 (CEST)
Abgerufen von „https://wiki.freieslabor.org/w/index.php?title=I_want_a_key&oldid=1679“