Hi,
On Thu, Feb 13, 2003 at 04:21:24PM +0100, Tobias Kaefer wrote:
> > Kommt mir das nur so vor oder ist diese vorgehensweise reichlich
> > idiotisch? Ich mache bei sowas einen TCP Socket auf und schieb die Daten
> > direkt an die Applikation.
>
> Also ich spreche da aus eingener Erfahrung.
> So einen selbstgestrickter Server ist schon etwas
> feines, nur bis man alle Aspekte für die Schnittstellenbeschreibung hat dauert
> es meist länger als einfach etwas vorhandenes zu benutzen.
TCP/SSL Socket -> Login: <user> -> Password: <password> -> data bis EOF
Geht sicherlich nicht immer, aber ziemlich oft und geht in Perl unter 10
Zeilen von der Hand, für die Daten die Kommen mußt du eh einen Parser
schreiben ;-)
Und die Datenfelder wollen in jedem Fall auch ersteinmal spezifiziert
sein.
> Ausserdem sind Protokolle wie ftp, ssh, sftp etc. eben schon erprobt.
> Sicherheitsrisiken sind bekannt oder aus der Welt geschaffen worden.
Ack. ssh könnte man zum Beispiel auch für so einen dienst verwenden,
einfach eine Applikation schreiben die sich da ranconnectet. Oder halt
per SSL. Sockets sollte man in jeder Programmiersprache ohne Probleme
öffnen können. ;-)
> Natürlich ist dateibasiertes arbeiten nicht so vornehm und schick, wzb. eine
> eigene Upload-Klasse und der entsprechenden Server dazu.
> Es geht aber meist schneller in der Entwicklung.
Es ist nicht nur vornehm und schick, folgende dinge wollen beachtet
werden:
- Mehrere Benutzer dürfen sich nicht gegenseitig Daten überschreiben
(Wird durch mehrere Verzeichnisse gelöst)
- Der Upload muß fertig sein bevor der Parser auf der Serverseite
anspringt. (Wird durch zwei weit auseinanderliegende Crons gelöst)
- Du brauchst eine FTP Klasse im Client. oder einen FTP Client.
- Wenn der Parser läuft darf der Client keine neuen Daten schicken.
- Der Parser muß testen ob neue Daten da sind.
- Einer meiner Lieferanten hat einen Satz Produktbilder (ca 30 MB) ich
habe dank zip keine Chance nur neue Bilder anzufordern. und das über
ISDN.
> Und die Zeit für die Entwicklung wird eben bezahlt und nicht wie schön das
> Programm übers Netzwerk kommuniziert.
Ebend! Deshalb meine Frage, geht das wirklich schneller? Ist das
wirklich billiger?
Ein Fallbeispiel: $COMPANY braucht für die eigene Groupwareapplikation
die sich an keinen mir bekannten Standard hält eine Schnittstelle zum
Mailserver um benutzer anzulegen.
ssh fällt aus, kann $PROGRAMMIERER nicht
Vorschlag a:
immer wenn ein neuer benutzer angelegt wird wird ein CSV
File gebaut auf einen Server gelegt. Alle X Minuten wird
nachgesehen ob das file neu ist, dann werden die benutzer
eingetragen oder entfernt.
Vorschlag b:
Die komandos werden über einen tcp socket gesendet wesentlich
schneller auf dem Server implementiert, Und der client braucht
sowieso ein paar zeilen code zum uploaden......
Oder $AUFTRAG:
$WATCHING Software erzeugt per perl script CSV Files die dann
auf einen NetSaint Server übertragen werden um dort events
auszulösen. Klasse weil $WATCHING Software hat genau wie
NetSaint eine Perl Schnittstelle, den Zeitraubenden Umweg über
CSV kann man sich glatt spaaren.
Und solche Aktionen erlebe ich irgendwie immer(!) wenn ich CSV per FTP
höre. Kann sein das das ein Vorurteil ist, aber ich finds eben
Idiotisch!
> Anders sieht das aber aus, wenn man den Applikationsserver als Basis für
> diverse Produkte entwickelt.
> Dieser Mehraufwand lohnt sich schon eher.
> Nur ist die Entwicklung, dann eben zeitaufwendig und daher auch teuer.
Ja, da wirds ja auch richtig gemacht ;-)
bis denn
--
May the source be with you!
----------------------------------------------------------------------------
PUG - Penguin User Group Wiesbaden - http://www.pug.org
