An mehrere Programminstanzen übergebene Daten zusammenführen

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
fbuchinger
User
Beiträge: 29
Registriert: Donnerstag 7. September 2006, 21:30

Sorry für den dummy-mäßigen Betreff, aber mir fiel nichts besseres zu meinem Vorhaben ein.

Ich arbeite an einer kleinen Applikation, die von verschiedenen Fotoverwaltungs-Tools (Picasa, Irfanview et al) ausgewählte Bilder übergeben bekommt und diese dann thumbnail-mäßig im Webbrowser darstellt. Dort gibt es dann Upload-Möglichkeiten zu verschiedenen Fotosharing-Diensten.

Workflow aus der Sicht des Users: ein oder mehrere Bilder im Fotoverwaltungs-Tool auswählen -> "in externem Editor öffnen" wählen -> nach kurzer Zeit startet der Browser mit der Fotoauswahl und weiteren Aktionsmöglichkeiten.

Die Schwierigkeit: Die meisten Fotoverwaltungs-Tools starten pro Bild eine Instanz meiner Applikation und übergeben dieser den Dateipfad des Bildes. Wie schaffe ich es, die Dateipfade aus allen Instanzen zusammenzuführen und den integrierten Webserver meiner Applikation (web.py) rechtzeitig zu starten?

Die Lösung sollte natürlich auch für 100 selektierte Fotos halbwegs performant sein (zumindest aber den User-Rechner nicht einfrieren) und insbesondere unter Windows funktionieren.

Weitere technische Eckpunkte:
* Applikation wird mit py2exe in eine .exe übersetzt
* ich plane web.py + dessen integrierten Webserver zu verwenden, bin aber für andere Vorschläge offen.
* bei meinen Tests stellte ich fest, dass die Fotoverwaltungs-Tools die Instanzen meiner Applikation quasi parallel starten, d.h. es wird auf keinerlei Rückgabewerte etc. gewartet
BlackJack

@fbuchinger: Du müsstest bei jedem Start Deiner Anwendung prüfen, ob schon ein Exemplar läuft, und wenn ja, dem den Dateinamen übermitteln. Üblich ist bei soetwas zum Beispiel, dass sich das Programm an ein Socket bindet und da lauscht. Die Portnummer ist entweder fest, dann kann ein weiteres Exemplar erkennen, dass es nicht das einzige ist, weil der Port schon belegt ist, oder man schreibt den Port in eine Lockdatei. Anhand der Datei können dann andere Exemplare erkennen, dass das Programm schon einmal läuft und da auch den Port auslesen für die Kommunikation.
fbuchinger
User
Beiträge: 29
Registriert: Donnerstag 7. September 2006, 21:30

einen ähnlichen Mechanismus habe ich bereits umgesetzt. Jede Instanz versucht zunächst über einen HTTP GET-Request den Dateinamen an den Server zu schicken. Schlägt dies fehl, versucht sie selbst, den Server zu starten.

Die Kommunikation über Sockets ist aber sicher effizienter..
BlackJack

Dafür ist HTTP einfacher zu implementieren weil man sich nicht mit dem ganzen Low-Level-Kram herumschlagen muss.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Da so etwas öfters vorkommt, gibt es sogar eine eigene Library dafür, die libunique.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
fbuchinger
User
Beiträge: 29
Registriert: Donnerstag 7. September 2006, 21:30

Ist libunique unter win32 verfügbar? Scheint zudem GTK vorauszusetzen, das wär mir ein bisschen zu heftig...

Kennt ihr empfehlenswerte IPC-Bibliotheken, die mit weiterhelfen könnten (pyro, multiprocessing, ...)?

Leider gehen alle dieser Libs davon aus, dass man selber die Prozesse dispatcht, in meinem Fall ist das aber nicht so.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

fbuchinger hat geschrieben:Ist libunique unter win32 verfügbar? Scheint zudem GTK vorauszusetzen, das wär mir ein bisschen zu heftig...
Tatsächlich, setzt GTK+ vorraus (was aber kein Hindernis für Win32 wäre, das Problem ist eher DBus). Eigentlich interessant, denn ich finde nicht, dass es eine Abhängigkeit zu GTK+ haben sollte. Eigentlich kann man sich so eine Library relativ einfach mit DBus selbst besteln, für sowas ist das Ding ziemlich optimal. Unter Windows würde man dann eher auf COM zurückgreifen.

Falls du mit Built-In-Sachen auskommst - es gibt in Python XML-RPC.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
fbuchinger
User
Beiträge: 29
Registriert: Donnerstag 7. September 2006, 21:30

Irgendwie ist mir der Prüfen-ob-Server-läuft-ansonsten-selber-Server-starten-Ansatz zu fragil. Da vergehen 1,2 Sekunden, bis der von der ersten Instanz gestartete Server hochkommt und in dieser Zeit versuchen natürlich andere Instanzen ebenso einen Start.

Mein neuer Ansatz: schau mir die Windows-Prozessliste an, wenn dort bereits ein Prozess meiner .exe läuft, dann wird versucht, dessen Server zu kontaktieren (natürlich mit Zeitverzögerung und Retrys).

Sehe mehrere Vorteile in diesem Ansatz:
- Das Prozess-Lookup geht relativ schnell (ca. 2 Hundertstel-Sekunden)
- Ich weiß, wieviele Instanzen meines Programms aktuell aktiv sind und kann daraus einen individuellen Timeout-Parameter für die Server-Requests der Instanz ableiten --> der Server wird nicht gleichzeitig von allen Instanzen gequält.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Sehe mehrere Nachteile:
  • Python-Skripte sind keine EXE-Dateien
  • Windows-spezifisch
  • Wer sagt dir, dass nicht ein anderer Prozess der genauso heißt wie deiner nicht schon läuft?
Das kommt mir noch ein gutes Stück fragiler vor.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
fbuchinger
User
Beiträge: 29
Registriert: Donnerstag 7. September 2006, 21:30

Ich denke einen Versuch ist es wert. Plane mein Skript sowieso als .exe zu distributen, die Prozesserkennung könnte ich auch für Linux implementieren und möglicherweise kann ich mit ein paar Zusatzparametern (Dateigröße) auch die Verwechslungsgefahr bei gleichlautenden Dateinamen in den Griff bekommen.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

fbuchinger hat geschrieben:Ich denke einen Versuch ist es wert.
Ja, worse is better :)
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Antworten