Hallo Forum,
ich möchte hier mein Projekt "skarabäus" vorstellen.
Die Motivation des Projektes ist, dass man jemand anderem Dateien zukommen lassen möchte, sich aber nicht mit Emailquota, Instantmessengern, ftp-Zugangsdaten etc rumschlagen möchte.
Mit dem Client (pyGTK) lädt man die fragliche Datei auf den Server (Werkzeug, Jinja) hoch, und erhält eine zufällige url, die man bequem im IM oder sonstwie dem Empfänger geben kann.
Der Empfänger kann die Datei sofort anfangen herunterzuladen, auch wenn man sie gerade noch hochlädt.
Client und Server kann man hier downloaden.
http://www.flyingelephantsoftware.de/pr ... lient.html
Kritik (auch an der Seite) ist sehr willkommen.
Skarabäus
-
- User
- Beiträge: 21
- Registriert: Freitag 21. April 2006, 17:01
- Kontaktdaten:
Absolut unwichtig, aber in core.py hat die Funktion upload() alle Parameter bis auf 'filename' dokumentiert - wenn man dann nur die Doku liest wundert man sich woher upload() weiss, was es uploaden soll...
Danke für die Antworten!
Uff, bei nährerer Betrachtung fällt mir auf, dass die core.py eigentlich etwas aufräumarbeit vertragen könnte...
Werd ich beizeiten mal überarbeiten.
ja, da ist was dran. ist im aktuellen SVN kommentiert.Absolut unwichtig, aber in core.py hat die Funktion upload() alle Parameter bis auf 'filename' dokumentiert - wenn man dann nur die Doku liest wundert man sich woher upload() weiss, was es uploaden soll...
Uff, bei nährerer Betrachtung fällt mir auf, dass die core.py eigentlich etwas aufräumarbeit vertragen könnte...
die vom unteren, linken Segment vermute ich?Das Skarabäus-Logo hat ne unrealistische Reflektion
Werd ich beizeiten mal überarbeiten.
Es sieht auf alle fälle sehr interessant aus. Ich werde es am Wochenende mal auf meinem Server installieren und gucken, wie es sich benutzen lässt. Ist auf alle fälle ne nette Alternative zu FTP 
MfG EnTeQuAk

MfG EnTeQuAk
Ja, das stimmt natürlich. Allerdings bin ich bis jetzt noch nicht dazu gekommen, das so zu packetieren, dass man es unter win zum laufen bekommen würde.mkallas hat geschrieben:Auch Programme mit GTK laufen unter verschiedenen OS, wie man z.B. an The Gimp sehen kann.
Bezüglich Paketen ist meine Priorität erstmal:
PyPI (irgendwie mögen die keine umlaute im Namen, scheint mir.)
RPM
Debian/Ubuntu
Windows und andere OS
Bis ich mir Wireshark angeguckt hab, hatte ich es auch schon aufgegeben, da meine Versuche in Windows auf eine Open-Source-Typische Art Hässlich wie die Nacht waren, und ich da nicht noch Öl ins Feuer giessen wollte

-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Da brauchst du nichts speziell zu paketieren. GTK+-Runtime für Win32 + PyGTK und das ist alles. Was du machen kannst, ist für lesensunkundige Nutzer ein All-in-One-Paket zu schnüren.keppla hat geschrieben:Ja, das stimmt natürlich. Allerdings bin ich bis jetzt noch nicht dazu gekommen, das so zu packetieren, dass man es unter win zum laufen bekommen würde.mkallas hat geschrieben:Auch Programme mit GTK laufen unter verschiedenen OS, wie man z.B. an The Gimp sehen kann.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Am besten einen komfortablen Installer mit InnoSetup oder NSIS. Ich persönlich mag sowas ja, denn für einen Linux-Paketmanagement-verwöhnten Nutzer ist die Vorstellung, drei Installer hintereinander ausführen zu müssen für eine einzige Software ein bisschen komischLeonidas hat geschrieben:Da brauchst du nichts speziell zu paketieren. GTK+-Runtime für Win32 + PyGTK und das ist alles. Was du machen kannst, ist für lesensunkundige Nutzer ein All-in-One-Paket zu schnüren.keppla hat geschrieben:Ja, das stimmt natürlich. Allerdings bin ich bis jetzt noch nicht dazu gekommen, das so zu packetieren, dass man es unter win zum laufen bekommen würde.mkallas hat geschrieben:Auch Programme mit GTK laufen unter verschiedenen OS, wie man z.B. an The Gimp sehen kann.


Edit: Mich würde noch interessieren, in wie weit du den Service für andere zu öffnen gedenkst. Nicht jeder ist mit Gtk glücklich, manche bevorzugen sogar nur CLI. Eine Dokumentation zur Service-API wäre also gut, da andere so eigene Clients schreiben könnten, ohne unbedingt die Quellen lesen zu müssen.
Das setup-Skript würde ich mit setuptools neu schreiben, dann kannst du dir nämlich auch das Run-Skript sparen, da das bei der Installation automatisch angelegt werden kann. Dazu kommen noch weitere Vorteile, wie das automatische Einschließen aller relevanten Dateien in die Source-Distribution oder die Integration von Babel zur Verwaltung der gettext-Dateien.
Ich hab etwas im Setup herumgefummelt, Version 0.4.1 des servers ist nun verfügbar.
Mann, mann, das Releasen ist ja deutlich mehr Arbeit als das Programmieren, scheint mir. Ich dachte immer, das warten wäre das, was die meiste Zeit braucht...
zZ führt man einen http-request nach /createid?username=x&password=y&filename=z aus, der eine xml-antwort liefert, die die "fileid" und die urls, wo man die eigentliche Datei hinposten soll, wo man eine vorschau sehen kann und wo man sie runterladen kann enthlält.
Mann, mann, das Releasen ist ja deutlich mehr Arbeit als das Programmieren, scheint mir. Ich dachte immer, das warten wäre das, was die meiste Zeit braucht...
Ich hab mich bemüht, die Programmierung modular zu halten, vieles sollte austauschbar sein, vielleicht kannst du es dadurch nah an das heranbringen, was du programmieren wolltest.Super Sache - Danke! Wollte kürzlich etwas ähnliches machen, hatte dazu aber keine Zeit. Werde es heute mal testen.
An Windows mach ich mich, sobald ich mit der "einfachen" installation glücklich bin, und wenn der VMWare-Server für Hardy Heron verfügbar istlunar hat geschrieben:Am besten einen komfortablen Installer mit InnoSetup oder NSIS. Ich persönlich mag sowas ja, denn für einen Linux-Paketmanagement-verwöhnten Nutzer ist die Vorstellung, drei Installer hintereinander ausführen zu müssen für eine einzige Software ein bisschen komischUnd der normale Windows-Nutzer kommt ohne setup.exe eh nicht weit

Ich wollte das auf jeden Fall offen halten, allerdings bin ich mir noch nicht so sicher, ob die aktuelle API so der Weisheit letzter schluss ist, und da "offenheit" imho irgendwie auch "standardisiert" heist, wollte ich erst was "offizielles" veröffentlichen, wenn ich mir da sicherer bin.Edit: Mich würde noch interessieren, in wie weit du den Service für andere zu öffnen gedenkst. Nicht jeder ist mit Gtk glücklich, manche bevorzugen sogar nur CLI. Eine Dokumentation zur Service-API wäre also gut, da andere so eigene Clients schreiben könnten, ohne unbedingt die Quellen lesen zu müssen.
zZ führt man einen http-request nach /createid?username=x&password=y&filename=z aus, der eine xml-antwort liefert, die die "fileid" und die urls, wo man die eigentliche Datei hinposten soll, wo man eine vorschau sehen kann und wo man sie runterladen kann enthlält.
Das runscript ist gleichzeitig auch die konfigurationsdatei, und die Konfiguration ist sehr offen gehalten, so dass ich es für nicht so einfach halte, da einen befehl draus zu machen.Das setup-Skript würde ich mit setuptools neu schreiben, dann kannst du dir nämlich auch das Run-Skript sparen, da das bei der Installation automatisch angelegt werden kann.
Ich hoffe, ich hab durch die letzte Version nicht jeden vergrault, der es getestet hat. Die nicht erwähnten abhängigkeiten habe ich nun gefixed, und (so hoffe ich) einiges leichter gemacht für den Server (stand-alone-skript, z.B.).
Ich würde mich über feedback wieder freuen!
http://flyingelephantsoftware.de/projec ... erver.html
http://flyingelephantsoftware.de/projec ... lient.html
Ich würde mich über feedback wieder freuen!
http://flyingelephantsoftware.de/projec ... erver.html
http://flyingelephantsoftware.de/projec ... lient.html