NETDUMP "standard"

netdump ist absichtlich client-lastig konzepiert worden. eine erweiterung auf seiten der server soll möglichst einfach gestaltet sein. die dynamik der erweiterung und skalierbarkiet des gesamten netdump netzwerkes steht absolut im vordergrund. beliebig viele ftp server können jederzeit das netdump depot erweitern. außerdem wird von den ftp servern keine servererweiterung erwartet. die erstkonfiguration besteht lediglich aus erstellen von zugriffsrechten und einer vorgegebenen verzeichnisstruktur, die von einem dumpmaster utility automatisch innerhalb von wenigen minuten vorgenommen werden kann. die clients hingegen sollen den benutzern maximale benutzerfreundlichkeit bieten können. die komplexität des funktionalismus wird hinter dem gui verborgen. die clients müssen keine konfiguration vom benutzer aus erleben. sowohl der netdump recycle bin, als auch der netdump collector sind sofort einsatzfähig. für den versierten anwender finden sich trotzdem so einige optionen und funktionen füer eine optimale anpassung im popup menü in der systray leiste.

die vorteile der client-lastigkeit liegen aber nicht nur an der simplen netdump kapazität erweiterung. die betriebssystemnahe eingliederung der clients erlaubt funktionen, die anders nicht möglich wären. wie schon erwähnt liegt der augenmerk vorallem an einer menschlichen und nicht technischen bedienbarkeit. mit den eingegliederten clients besteht die möglichkeit, in ihnen features zu verpacken, sodass eine natürlichkeit in der verwendbarkeit entsteht, die aus sämtlichen ideen des konzeptes ohne einbussen 1:1(!) umzusetzen sind. keine kompromisse.

automatische datenmüllsotierung, extrahieren von dateiinformationen, konvertierungen, previews, datastreams, verschiedenste suchfunktionen, dateisystem modifikationen und vieles mehr können so als für den benutzer vom gui isolierte grundlage dienen.

 

NETDUMP 2 ACTIVE (possible future release parallel to standard netdump)

trotz genannter vorteile der derzeitigen und einzigen netdump version gibt es natürlich ebenso nachteile, die gründe für die parallele entwicklung einer zweiten netdump variante darstellen könnten. netdump "standard" ist derzeit einerseits nur unter windows lauffähig und andererseits setzt diese variante eben aus dem internet zu installierende clients voraus. dieses manko kann nun wiederum im umgekehrten falle durch "fat servers" aus der welt geschafft werden. so hätte man hier sämtliche services auf den servern laufen und die erweiterbarkeit des netdump netzwerkes wäre mit einem schlag enorm kompliziert und aufwendig. andererseits wäre der benutzer von netdump dann nicht mehr auf bestimmte betriebsysteme bzw installationen und downloads angewiesen. die clients in diesem fall wären einfache scripts, die in webbrowsern einfach und schnell ausgeführt werden können. konvertierungen, und ähnliche leistungen würden gänzlich von den servern übernommen werden. nachteil: server würden zusätzlich BElastet und die client rechner ENTlastet werden. die gefahr, die es hier zu beachten gilt: es können unter umständen längere wartezeiten auftreten, da die server plötzlich eine unmenge an datenanforderungen abzuarbeiten haben. nebenbei muss auf eine in die browserbedienungsgewohnheiten einzugliedernde benutzeroberfläche der clients geachtet werden. dies sind probleme, die es noch auf kreative unkonventionelle wiese zu beseitigen gilt.

ein schritt zur umsetzung dieser server aktiven variante wäre die umfangreiche verwendung von dateiformat konvertierungen. der benutzer kann zu jeder datei des netdump netzwerkes das für sich persönlich am besten verwendbare format aus eine liste aller konvertierungsmöglichkeiten auswählen. der server bereitet dann die datei dementsprechend auf und der benutzer kann sich sicher sein, das format auch ausführen/ anzeigen/ abspielen bzw. verarbeiten zu können. eine liste möglicher konvertierungen einiger dateiformate ist hier in einer ersten version zu sehen: goto> convertable and supported fileformats.

 

 



last html-update: 29.feb 00 // last content-update: 29.feb 00
copyright (c) Gerhard Schwoiger, 2000 // contact: gerhard@v-a-m-p.com