OrgaMon-next

OrgaMon-Sprach-Basis

• OrgaMon soll einen Kernel haben, der auf "C" oder "C++" basiert - ich will vom Delphi wegkommen, da es kein OpenSource ist
• ECommerce und Verarbeitung soll in einer IDE+Debug fähigen sprache verfasst sein, welche ist eigentlich egal. Doch der Kunde drausen um einen Break-Point setzen können und neben einem "grauen" Sprachbereich seinen eigenen COde eintragen können. Dazu öffenet das OrgaMon System Kopplungspunkte.

OrgaMon-Map

• OpenStreetview
  • Im ersten Schritt soll der /tile/ Dienst vom Web genutzt werden
  • Später soll mit mapnik ein eigener Renderer auf Linux Basis eingesetzt werden

• Google-Mpas
  • Im ersten Schritt soll ein Google-Map Api eingesetzt werden um gerenderte Karten zu laden
  • Nachdem OpenStreetview stark genug ist soll dies wieder sterben

• Geolokalisierung
  • Soll weiterhin mit dem xServer betrieben werden

Quellen

[1] http://delphimaps.googlecode.com/svn/trunk/
[2]
[3] mapnik
[4] http://weait.com/content/build-your-own-openstreetmap-server
[] http://DelphiFeeds.com
[] http://www.delphifeeds.com/go/f/70742?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+delphifeeds+%28DelphiFeeds.com%29

OrgaMon-Internet

das OrgaMon-Internet verschiebt Datenbank (mit allen Diensten: eMail, Tagwache, Tagesabschluss) und teilweise den Dateiablagebereich in Internet. Die Datenbank-Operationen werden 100% auf einem Server durchgeführt, die Dateioperationen müssen teilweise per "save" and "send" (Lokales speichern auf dem Server UND senden an den Clioent) oder "save" und "replicate" (lokales speichern und replizieren wenn es die Bandbreite zu lässt).

Kopplung des Applikationsservers mit dem Client

der Client ist immer grundsätzlich vollständig, das bedeutet er "könnte" auch alle Funktionen lokal mit einer eingenen Datenbnak und auf dem eigenen Dateisystem ausführen. Intern im OrgaMon sind je nach Mandant die Ausführungswege jedoch anders gesteuert. Ich denke dies erfolgt intern mit dem Umimplementieren einiger eCommerce-Funktionen in ein Interface.

TRemotable
TInvokableClass muss nicht unbedingt sein.

Die Systeme sollen aber auch umfassendes Verständnis von Caching haben. Wie bereits an anderer Stelle angedeutet spielt hier der eTag eine ganz besondere Rolle. Der Client stellt unwissend eine Frage (eTag noch "null") er bekommt die Antwort UND den eTag. Das nächste Mal stellt der die völlig identische Frage nochmals (diesmal mit dem erhaltenen eTag im Header). Nun ist es am Server zu sagen "unchanged" oder neuer eTag und Content.

OrgaMon Gate

soll eingehende Anfragen beantworten. Dabei muss das Gate als Router funktionieren um die Requests auf den passenden OrgaMon-Ghosts weiterzugeben.

• "Mandant" beschreibt mit welchem Mandant konnektiert werden soll
• "Client" beschreibt eindeutig die Endpunkt-Instanz, neuer Start des OrgaMon auf dem Client -> neue OrgaMon Instanz

Mögliche Implementierung

• Apache2, https!
• mod_asis geht ev. Hand in Hand mit dem etag Caching System
• Proxy VOR den einzelnen mandanten http://httpd.apache.org/docs/2.0/mod/mod_proxy.html
• Kompression mit Hilfe von zlib und Standard HTTP Techniken

OrgaMon Ghosts

(1:1 instanzierung des Applikationsserver)

Mit einem OrgaMon-Client kann man auch eine extra gestartete Ghost Instanz (1:1 Beziehung) des OrgaMon über eine TCP/IP Verbindung konnektieren. Ein Dispatcher hilft dabei bei der Konnektierung zwischen Client und Ghost, ev. auch mal bei einem Re-Connect.

Buisiness-Logik Funktionen werden auf dem Migrationsweg zunehmend über "Interfaceable" Datenmodule abgewickelt. Im OrgaMon müssen nun Datenmodule entweder ...

• lokal konnektieren, dann läuft die Funktion über die lokale CPU ab, sie operiert dabei mit der angegebenen Datenbank und dem angegebenen Dateisystem.
• remote konnektieren, die Funktionsaufrufe werden sequenzialisiert und zum remote übertragen. Dieser führt den Code unter veränderung der dortigen Datenbank und des dortigen Dateisystems aus. Der Rückgabewert wird wiederum über TCP versendet.

File Sync

Es ist möglich dass im Rahmen der Codeausführung auf dem Server Dateien im lokalen Dateisystem des Servers auf den Client synchronisiert werden müssen. Der Server Code muss diese Dateinamen einem SynDienst melden: Dieser wird sofort eine Synchronisation durchführen. Entsprechende Anfragen muss die entsprechende Routine dem Interface mitteilen, da VOR Zurückkehren der Routine auch das Dateisystem sychronisiert sein muss! (Es sei denn auf dem Client gibt es eine ensure(FName) Funktion die Signalisiert, dass diese datei JETZT wieder gebraucht wird, ensure würde in diesem Fall warten bis die Datei da ist!) Ansonsten kann diese Aktion asynchron ablaufen. Entstehen nun auf dem Remote neue Dateien, so wir als Funktionsergebnis das initiieren eines FTP Downloades gefordert, der Client holt sich also die Ergebnisse über FTP ab, und spiegelt sie auf der lokalen Platte nun wieder.

während der Laufzeit muss eigentlich das Interface nahtlos austauschbar sein.

Datenbank-Caching

Da Datenbankabfragen mit teilweise sehr grossen Antworten "select * from" einhergehen in Verbindungs damit dass ofmals ein "Refresh" notwendig ist. Ist das Caching von Datenbank-Werten erlaubt und wird durch eine besondere Technik unterstützt.

Client->Server: SQL-Anfrage
Server->Client: Cache_ID & Antwort-Paket
später
Client->Server: SQL-Anfrage (identisch)
Server: Cache_ID

oder auch
Client->Server: Cache_ID?
Server: "valid"

Interface-Ablauf

Call

Der Client iniziiert einen Call über http. Es sendet seinen Cache ID im etag mit. Dem Server seht es frei diesen eTag zu bestätigen oder ihn zuverwerfen.

Feedback

Zusammen mit dem Client-Call wird ein Feedback Interface (optional) installiert. Damit liefert der Server Zwischen Infos seiner Bearbeitung ab. Dies ist für das Logging wichtig. Bei langdauernden Aktionen des Servers dient das Feedback Interface zur Fortschrittsanzeige. Eine Variante des Feedback-Interface ist einfach eine "Diagnose.txt" die nach Abschluss der Funktion üder den Dateisystem-Sync übertragen ist.

Interface-Caching

sagen wir mal, wir haben:

type
 DataModuleeCommerce = class(GhostAbleInterface)
 
 published
  TodaySettings : TStringList;
 end;

wir sagten ja ein lokaler OrgaMon kann auf TodayStrings zugreifen, als wäre das lokal

OrgaMon-GUI

UI Ideen

ein Projekt, das zum Ziel hat den OrgaMon mit einer Plattform-übergreifenden GUI anzubieten

farbige Tabs

• Tab sind erst mal nicht da, können aber aus einem Suchbegriff oder einem Befehl frisch erzeugt werden. Wird z.B. ein Vertrag angewendet entstehen ev. ganz viele neue Beleg, ein Beleg wir als ein einzelner Tab angezeigt.
• Standard-Aktionen sind auf Tabs anwendbar und können als transaktion auf Gruppen von TAbs angewendet werden.
• Eine aktuell eingerichtete Tab-Gruppe (3 Personen und 2 Beleg und 1 Vertrag) kann in einer Tab-Historie gespeichert werden.
• Tab-Favoriten gibt es auch, auf die "Umgeschaltet" werden kann aber auch "dazugeladen" werden kann.
• man kann mehrere Belege öffnen und gleichzeitig bearbeiten. Dazu "Zieht" man sich einen neuen Tab. Tabs aus der selben Gruppe haben die gleiche Farbe und sind immer zusammen angeordnet (Gruppe schliessen).
• Es gibt einen Neu Tab.
• Ein Langer gehaltener Klick auf einen Tab erzeugt einen "Drag"-Event

Tab-Funktionen

Anklicken: Der Tab-Inhalt kommt nach vorne, jetzt erst wenn der TabInhalt sichtbar ist wird das kleine "close" sichtbar.

Progressbereich

• zeigt zentral aktuelle Wartezeiten an, im Hilfehinweis oberhalb laufen Log meldungen
• ich bin unsicher, ob dies durchführbar ist, aber ich will eine Unstoppable GUI die einfach nur Anforderungen an eine Exekutive weitergibt. In dem Progressbereich stapeln sich einfach Aufgaben, die im Moment am laufen sind und noch nicht abgeschlossen (Beispiele Dafür: Tagwache auf einem Server, Tagesabschluss auf einem Server, Anwendung von Verträgen usw.)

Suchbereich

OrgaMon ist (wieder) über Hotkeys steuerbar: <ctrl>PN macht "Person" "neu" der Focus steht beim Vornamen usw.

blauer Aqua-Button

der Start-knopf des OrgaMon, hier kommen die ganzen früheren Menü Möglichkeiten

Technologie Review

• FreePascal GTK+ Binding
• http://wiki.freepascal.org/Qt4_binding
• http://www.rodi.dk/programming_cairo.php
• http://wiki.lazarus.freepascal.org/
• http://www.fox-toolkit.org/
• http://gsl.openoffice.org/vcl/index.html
• http://gsl.libreoffice.org/vcl/index.html
• http://www.phoronix.com/scan.php?page=news_item&px=ODgzMA
• http://www.micrel.cz/Dx/
• http://www.foss-group.ch/de/Anwendungen/OSBD/

aktuelle Tendenz

OrgaMon versucht wie OpenOffice eine ganz normale Anwendung zu sein die für verschiedene Plattformen compiliert werden kann. Ev. macht sie auch Gebrauch von den jeweiligen Möglichkeiten des Betriebssystems ...

UI Implementierungen

Browser-Technologie

GUI ist immer im Browser als Web 3.0 Anwendung (HTML 5.0, jquery, JetPack), es gibt einen passiven Content-Provider, ev. eine PHP Apache-Kombination. Aktuelle Formulare sollen jedoch rein aus einem JSON Interface gewonnen werden, die Kommunikation erfolgt direkt zwischen XMPRequest und dem aufgebohrten cXMLRPC (der ja auch mal unter Linux laufen soll).

• Wie das Design der Fomulare erfolgen soll weiss ich noch nicht (also mit welcher IDE, XML Definitionen, ...)
• Die Bedienelemente sollen ganz einfach beginnen und dann Schritt für Schritt mächtiger werden
• In einer Übergangsphase soll ein Webkit in den OrgaMon.exe integriert werden (der OrgaMon wird z.B. auch einen Magnetstreifen scannen müssen, oder Datensicherung machen, oder den Computernamen abfragen, oder?)

OrgaMon

Ein vollständiger OrgaMon.exe läuft beim Kunden. Die wesentlichen Funktionen laufen jedoch über remoteable APIs. dabei wird das caching Projekt mit der etag Technologie verknüpft. Auf Server-Seite läuft ein eigener Webserver mit ETAG Funktionalität

http://developer.yahoo.com/performance/rules.html