open API
Opened this issue · 2 comments
Ich verwende mal die deutsche Sprache da der Innitiator ja ein deutscher ist.
Facebook musste irgendwann die erfahrung machen, das speziel auf Smartphones ein Webinterface zu "clunky" und zu lahm und unpassend ist.
Ich rege mich inzwischen auch ueber jedes Forum jeder Newsseite oder sonstwas auf das ich da deren interface benutzen muss um das zu benutzen.
Natuerlich braucht solch ein Projekt ein Webinterface um Leute ohne setup direkt mal rein schnuppern koennen und vielleicht sogar damit zufrieden sind.
Wenn es aber um Skalierung geht oder um echtes Arbeiten, halte ich andere Interfaces fuer besser.
Das beste Beispiel hier finde ich Webmail vs Mailprogramme. Leute die effizient mit Mails arbeiten wollen, benutzen fast alle einen desktopclient. Und auf dem Smartphone verwenden auch die wenigesten Webmail.
Mail ist hier ein gutes beispiel, da hier ein offenes Protokoll verwendet wird, ohne beschraenkungen (man darf nur 1 mail pro tag versenden/empfangen oder so), und alle verwenden das selbe protokoll.
Letzteres eine standardisierung waere sicher schwer fuer HumanConncetion aber der Rest waere denkbar.
Der Hauptgrund warum Webseitenbetreiber bestenfalls eigene Apis mit vielen beschraenkungen an bieten, scheint mir daran zu liegen, das diese dort schwerer den Leuten Werbung aufzwingen koennen, sie Kontrolle verlieren, dies duerfte bei HC ja nicht das Problem sein.
Wie eine solche Schnittstelle aussehen koennte, weiss ich nicht genau, eine json schnittstelle wie z.B. bei Kodi waere denkbar, aber ja vielleicht habt ihr da ja eh schon eine interne API die ihr auch dokumentieren koenntet.
Vielleicht habt ihr dafuer momentan noch keine Zeit, aber man koennte mal mit teilbereichen an fangen.
Ich moechte hier auch mal noch nntp nennen sprich newsserver.
In grossen Opensource Projekten ist sowas die zentrale kommunikation, der Linux Kernel wird ueber Mailinglisten gemanaged aber auch etliche andere projekte.
Ich finde diese Spaltung der Community die Experten die quasi ihhre Tools nutzen und dann die gemeine Masse die die Tools verwenden die die Geeks/Eperten fuer sie gemacht haben, aber sie selbst im Zweifel gar nicht nutzen, fuer schlecht.
Das erzeugt auch Echochambers... diese Vorsellection sollte nicht geschehen anhand des Tools/UI/Frontends das man verwendet browser / Mail-client sollte nicht eine Community trennen.
Btw ist es beim Programmieren aenhlich, ich wuerde niemals an dem html/js client entwickeln mal nicht unbezahlt :) das ich aber in elisp mir selbst nen (teil)interface entwickeln wuerde oder dazu was beitragen wuerde, schon. Ich habe eben schon ein emacs client fuer Kodi geschrieben.
Man koennte das sogar aktivistisch argumentieren, wieviele Kraftwerke laufen, weil die Leute stark dazu gedraengt/gezwungen sind, den cpu auslastenden Browser fuer alles benutzen muessen.
Es gibt ja berechnungen das alleine die umstellung der google webseite auf Schwarz zig Kraftwerke ueberfluessig machen wuerden.
Wieviele Smartphones werden neu verkauft weil die webanwendungen staerkere CPUs / mehr ram brauchen und es nicht fuer alles wichtige apps gibt?
Auch waeren natuerlich effizientere Nutzung der Plattform gut, damit Leute schneller damit was projekte umsetzen.
Speziel textbereiche wie Chat / Forum oder sowas sollte man nicht ausschliesslich ueber Webinterface an bieten. Gerade dort wo man aehnlich wie bei Mails auch antworten kriegen kann, sollten das keine pull Nachrichten sein, wo man selbst auf die webseite gehen muss um sie zu erhalten sondern "pushnachrichten" auf die man direkt antworten kann.
Also nicht nur "push-notifications" wo man dann erst wieder zuerst den browser laden muss, auf die webseite geleitet wird, und dann dort antworten kann, nein direkt im desktop (chat/mail/...) client will ich direkt antworten koennen ohne umweg.
Interessante Punkte!
Vielleicht wäre es auch möglich einen IRC Chat einzubinden? 
Soll ja verschluesselt sein, daher bietet sich irc nicht an, ausserdem ist die frage wie man das einbinden will, sie haben ja einen chat client der vermutlich nicht auf irc basiert... damit muesste man nen eigenes protokoll anbieten.
Die clients schreiben ist gar nicht so das riesen thema, wenn nen api da ist. Siehe email da gibts auch 1000 clients draussen.
Zumal irc auch einige Probleme hat, man braucht nen eigenen server etc. Wenn ueberhaupt waere jabber noch interessanter, glaub sogar facebook unterstuetzt xmpp.
Wenn man wirlich auf sicherheit gehen will, waere sowas wie tox besser, leider gibts da keinen emacs client aber irgendwann wird es den geben :).
Vermutlich sogar bald, mit emacs 25.x kommt so ne C api schnittstelle damit sollte das machbar sein. Aber das jetzt schon wieder sehr spezieles Problem :)