We’re up to something

  • Beitrags-Autor:
  • Beitrags-Kategorie:Blog
  • Beitrags-Kommentare:0 Kommentare

Nokia scheint die Trennung vom Handy-Geschäft gut zu bekommen. Die heutige Ankündigung eines eigenen Android-Tablets zeugt von Umtriebigkeit und einer gewissen Dreistigkeit gegenüber dem ehemaligen Partner Microsoft. Klar – Nokia tritt hier lediglich als Namens-Spender für chinesische Hardware in Erscheinung. Aber pfiffig ist es allemal, um weiter im Gespräch zu bleiben 😆

Weniger schlau werde ich aus der Meldung über eine verstärkte Zusammenarbeit zwischen Nokia und SAP im Bereich Karten-Integration. Es ist von Kundennutzen bei der Verwendung des HERE-Kartenmaterials auf der SAP HANA Plattform die Rede. Aber will SAP damit nur nachziehen, was andere Hersteller wie Oracle mit ihrem Spatial Geocoder bereits vorgelegt haben, oder geht es um mehr – eventuell sogar Anwendungen, die damit turn by turn navigation durchführen können?

Keine Ahnung –  die obige Meldung gibt diese Information nicht preis. 😮
Immerhin wüsste ich eine Anwendung, welche die Option nutzen könnte! Anyway – das bringt mich zum eigentlichen Thema zurück – TwoGo, oder wie kann es weitergehen.

Client-Farm statt Server-Farm

Vor einigen Tagen habe ich mir überlegt, dass die Voraussetzung für eine Vermittlung auf einer Server-Farm im backend des Ridesharing-Betreibers angesichts leistungsstarker Smartphone-Endgeräte möglicherweise gar nicht mehr zwingend ist. Denkbar wäre stattdessen auch, dass der Betreiber lediglich die Vermittlungswünsche trackt, die Anforderungsprofile abgleicht und dann eine einfache Umkreissuche auf einer Geo-Datenbank (gefüttert mit HERE-Daten) durchführt. Der darauf folgende, aufwändige Streckenvergleich der möglichen Fahrer/Mitfahrer-Kandidaten würde aber nicht mehr auf den Servern des Betreibers durchgeführt. Stattdessen würde die ermittelte Liste der Mitfahr-Kandidaten auf das Smartphone des Fahrers (bzw. die dortige Navi-App) übertragen, um das ACDB-Routing direkt dort auszuführen! Abgesehen von der Entlastung der Infrastruktur des Betreibers könnten auch unnötige Berechnungen entfallen, etwa in den Fällen, wo sich ein angemeldeter Fahrer bereits ausgeklinkt hat (App beendet, Gerät ausgeschaltet), ohne sich explizit abzumelden. Der resultierende Kommunikations-Overhead zwischen Fahrer-Client und Betreiber-Server dürfte bei der Client-Farm-Variante steigen. Schätzungsweise sollte aber die Ersparnis an Rechenkapazitäten diesen Nachteil überwiegen

Schreibe einen Kommentar