VDRAdmind neu programmieren, nur schneller und sprachunabhängig

Hi ihr Leut

ich bin wie viele andere bestimmt auch ein grosser Fan von vdradmind. Die Funktionsvielfalt ist einfach wundervoll. Das einzige das bei mir Frust auslöst ist die verbesserungswürdige Geschwindigkeit mit der dieses Tool an die Arbeit geht.

Ich habe mir nun überlegt die Funktionalität von vdradmind neu zu implementieren aber nich in Perl sondern diesmal auf Basis von .NET. Warum .NET ? Na eigentlich hauptsächlich wegen den vielen Möglichkeiten die sich dadurch für potentielle Mitstreiter entwickelt. Das ganze ist nämlich dadurch an keine Programmiersprache gebunden. Ich werde in C# entwickeln, aber es steht mir und jedem anderen der mitmachen möchte weiterhin frei andere Teile oder Klassen der Implementierung in anderen Programmiersprachen anzufertigen, z.B. C++ oder Basic, oder Pascal, oder.... you name it

Und weil das alles halbsoviel Spass macht schreibe ich auch noch regelmässig über das ganze.

Das erste vorzeigbare ist fertig und über Kommentare und Anregungen bin ich offen.

[URL=http://maniac.rz.tu-ilmenau.de/schrankmonster/PermaLink,guid,f3f52724-2e7a-4524-9bd2-7eed6225467e.aspx]Teil 1 des Entwicklungs-Tagebuchs[/URL]

mfG. Daniel

Hi

ja klar. Ich entwickle das ganze zwar unter Windows im Visual Studio 2003 aber ich werde darauf achten das die ganze Geschichte auch genauso unter Linux läuft... benötigt wird unter Windows die Version 1.1 des .NET Framework. Und unter Linux Mono.

"Mono is a comprehensive open source development platform based on the .NET framework that allows developers to build Linux and cross-platform applications with unprecedented productivity. Mono's .NET implementation is based on the ECMA standards for C# and the Common Language Infrastructure."

weil ichs gern in C# programmieren will. Wäre kein Problem auch Java (bzw. das Derivat J#) zu benutzen... läuft ja auch auf der .NET Platform.... ist einfach eine Frage der Vorlieben

ich weiss das es XXV gibt. aber:

1. brauchts nen SQL Server
2. ists in Perl realisiert
3. schaden mehrere Ansätze ja nicht

... alles in allem find ich schon das ich was anderes tue als XXV

die Blogsoftware die ich verwende ist als OpenSource (BSD ähnliche Lizenz) verfügbar und heisst "dasBlog".

Selbstverständlich ist die Blogsoftware komplett in .NET geschrieben und auch sie funktioniert ohne eigene SQL Datenbank.

Zitat

Original von wastl
BieTieKay

dein eifer ist schoen, aber, ohne dich entmutigen zu wollen:

.NET wird in der unix/linux welt wohl eher auf ablehnung stossen. und das zurecht, wie ich meine (moechte nicht naeher darauf eingehen, aber als stichworte: patentierte verfahren, abhaengigkeit v. gutduenken microsofts uvm.)

es gibt ein Agreement mit dem Mono Projekt - und solange wir uns auf nicht-kommerziellem Gebiet befinden sind die Befürchtungen sowieso unbegründet.

Zitat

es ist nicht nur unbedingt blinde ablehnung gegenueber microsoft, die man in einem ersten urteil einer ablehnenden haltung gegen .NET unterstellen koennte, aber da gibt es bereits genug diskussionen und artikel zu diesem thema.

ich habe die Suchfunktion nicht nach für die Suche derartigen Diskursen genutzt, bin aber gerne bereit die Diskussion nocheinmal mit neuen Argumenten zu beginnen.

Zitat

dh: viele potentielle mitstreiter werden von .NET eher abgeschreckt als angezogen.

ich habe eben auch gerade was potentielle Mitstreiter betrifft schon Angebote. Insofern mach ich mir darum weniger Sorgen.

Zitat

auch ist das geschwindigkeitsproblem nicht unbedingt perl anzulasten (sondern wohl eher der art und weise der programmierung).

ja, das denke ich auch. Wobei man festhalten muss, dass Perl nun nicht dazu entwickelt worden ist um einen Webserver zu realisieren...

Zitat

vorteile von perl, python: (ueblicherweise) standardmaessig installiert, klein, sparsam.
vorteile von scriptsprachen allgemein (im webapplikationsbereich): schnellere entwicklung (kompilierung / deployment entfaellt, ..)

ich finde, das wenn jemand eine Software verwenden möchte, er auch die Bedingungen dafür schaffen kann/will. Das Argument "wir wollen doch Minimalsysteme" gilt meines Erachtens nur bei Systemen wie LinVDR. Ich kenne aber genug VDR-Enthusiatsten die durchaus ein Power-System zusammengeschraubt haben und sogar nen X11 auf ihrem VDR laufen lassen....vielleicht ist das meine Zielgruppe

Zitat

das engagement v. manuel de icaza bzgl. unterstuetzung v. .NET auf unix-plattformen ist zwar durchaus zu bewundern, nur wage ich (und viele andere auch) die prognose, dass .NET auf diesen plattformen nicht mehr als ein schattendasein fuehren werden (falls es nicht sowieso bald klagen von microsoft dagegen geben wird).

es wird keine Klagen von Microsoft geben solang keine kommerziellen Interessen direkt verletzt werden. Es gibt ein Agreement welches alle freien und nichtkommerziellen Projekte auf Mono Basis für "vogelfrei" erklärt... ergo lohnt es nicht sich im "Verklag-mich-Orakel" zu üben...

mfg. Daniel

Zitat

Original von sdu
Hallo,

es stellt sich für mich auch die Frage ob Technologien wie Mono (.NET) oder Java wirklich das richtige sind für eine Aufgabe wie VDRAdmin - hier paßt Perl oder auch Python doch wie die Faust aufs Auge

sicherlich ist Perl super geeignet um Texte zu parsen usw. usf.. Es ist aber definitiv nicht ideal geeignet um einen Webserver oder sonst irgendwelche Netzwerk-bezogene Aufgaben zu erledigen.

Ausserdem habe ich eben den Eindruck das Perl doch nicht SO schnell ist wie ich ursprünglich dachte. Anders kann ich mir auch nicht erklären wieso XXV die Datenbank in einen SQL Server auslagert statt sie mit Perl zu halten... (es werden ja imho auch Geschwindigkeitsgründe angegeben).

Ich finde dass .NET dort perfekt geeignet ist weil die anfallenden Datenmengen sicherlich spielend zu handlen sind. In Teil 1 des Projekts kann man sich auch den Quelltext und die entsprechenden Datenstrukturen ansehen.
Ich sehe auch den Vorteil das ich Leuten die noch nicht sogut programmieren können bzw. einmal einen Einstieg finden wollen durch die einfache und schrittweise Darstellung der Entwicklung beim lernen helfen kann.

mfg. Daniel

Zitat

OFF-Topic
ich denke das hauptargument für eine datenbank ist, dass perl sowas wie eine datenbank-struktur nicht mitbringt.
klar - es wäre möglich auch in perl eine abstrakte datenbank-schnittstelle zu implementeieren. aber wiso? - es gibt schon genug davon. und sql gegört dazu. es gibt bindings auch zu db2 und anderen sql datenbanken (dbi).

wir sind einer Meinung; ich finde schon das das Ontopic ist Geht ja auch und vor allem um Entwicklung.

.NET bringt eben diese Datenstrukturen und Datenbank-Schnittstellen in Form von ADO.NET mit. (Siehe Quelltext+Artikel ;))

Zitat

das perl eher ungeeignet ist für einen webserver - da gebe ich dir völlig recht. dazu gibts schon apache & co. aber das perl-script nur als cgi-laufen zu lassen ist in meinen augen völlig okay. dadurch kann man auch - im gegensatz zu vdradmind - mehere anfragen parallel laufen lassen. (vdradmind ist IMHO singlethread)

ich glaube das Geschwindigkeitsproblem welches vdradmind in meinen Augen hat nicht mit Single- oder Multithreading zu erklären ist. Weil der Thread der die HTTP Verbindung handelt wartet auch nur auf das Backend... ob nun auf mehrere Threads verteilt oder nicht ist da egal.

Zitat

und gerade die möglichkeiten die perl mit regexp&co. bietet machen es in meinen augen ideal dafür geeignet kleine aufgabe wie z.B. das parsen nach timern zu erledigen.

ähnliche Möglichkeiten bietet das .NET Framework. Deshalb habe ich es unter anderem auch für diese Aufgabe favorisiert.

Mal ein Beispiel zum Thema Datenbank-/Datenstruktur:

Ich kann an die Datenstruktur die ich im Teil 1 erstellt habe eine SQL Anfrage stellen. Ohne einen SQL Server zu installieren. Das beherrschen die verwendeten ADO.NET Klassen "out-of-the-box".... das finde ich persönlich sehr sexy

Teil 2: ein integrierter Webserver

Ich bin einen Schritt weiter und habe die Grundkonzeption fast fertig. Zwischendurch präsentiere ich den nächsten Teil der Serie. Diesmal geht es um die Entscheidung intern/externer Webserver und warum ich den internen Webserver vorziehe.

[URL=http://maniac.rz.tu-ilmenau.de/schrankmonster/PermaLink,guid,9f8fcfe7-4be1-48d2-9e7a-b0a27f03ba48.aspx]Hier gehts zu Teil 2.[/URL]

Zitat

hmm.. 22 kb? und das noch dazu als Zip?
dann noch mal 60+ Mb fuer mono.
ich denke ein Perl Loesung sind einige 100 bytes. (ein paar Zeilen)

naja...und Perl selbst ? Und die libs für Perl ? ... worüber regst du dich auf ? Über Dateigrössen ?

Zitat

Und was hackst du auf SQL rum? Was willst du heute noch ohne SQL? Telefonbuch, Sitebar, Wiki, Adressen, MP3, VDR-Aufnahmen und vieles mehr liegt bei mir auf Mysql, sogar ankommende Teleonfanrufe landen auf SQL. Openoffice kann z.b. auch problemlos mit mysql.

ja gut, schön schön. Aber es geht ja auch anders, ohne Komfort oder Geschwindigkeit einzubüssen.... und das will ich den Interessierten zeigen.

Was ich garnicht verstehe: Du kritisierst die Grösse einer Mono Installation, von der du für dieses Tool niemals die vollen 60 Megabyte benötigst, duldest aber andererseits einen Datenbank-Server... ein SQL Server löst erstmal nur das Daten-wegschreib-und-wieder-hervorkram-Problem.... kein anderes...

Zitat

EPG, Channel.conf usw. auf SQL waere mehr als genial.

und meine Aufnahme ist auf SQL. Wie stelle ich das dann z.b. mit mono/.net an?

vom Prinzip her ähnlich, wenn auch eigentlich von der Durchführung dann mit deutlich anderem Konzept.

Mal ein Beispiel: die momentan von mir angelegten Datenstrukturen umfassen nur Sender und die EPG Daten zu den Sendern. Ich kann aber jetzt schon, auch ohne einen SQL Server zu installieren, in C# oder jeder anderen .NET Programmiersprache SQL Anfragen an diese Datenstruktur stellen (nennt sich Dataset, welche DataTables enthält...die wiederrum mit DataRelations miteinander verknüpft sind)

Ich kann regexps auf die Datenstrukturen anwenden usw usf. Und das alles sozusagen "automatisch", das fällt dem .NET Framework mal nebenbei aus der Tasche...

Zitat

Ich finde eine Loesung mit perl/php... und mysql sehr gut, da es auf Tools basiert die in der Linux/Unix Welt sehr verbreitet sind.

meine Kritik bezog sich nicht hauptsächlich auf die gewählte Programmiersprache oder Datenbank. Sondern vielmehr auf die Durchführung und die daraus resultierende Geschwindigkeit. Ich weiss nicht wie schnell XXV ist. VDRAdmind jedenfalls ist deutlich zu langsam für die wenigen Daten die behandelt werden müssen.

Nebenbei: Nur weil etwas sehr verbreitet ist, ist es nicht automatisch die beste Lösung eines Problems. Aus eigener Erfahrung weiss bestimmt jeder selbst am besten das die besten Lösungen häufig eben (noch) nicht weit verbreitet sind.

Zitat

Auf mono oder .NET bin ich persoenlich jedenfalls nicht scharf.
Und irgendwie fuerchte ich, mit deiner Loesung geht Netzwerk Transparenz verlohren.

was genau meinst du mit Netzwerk Transparenz ? Meinst du das der User nichtmehr sieht was über sein Netzwerk läuft ?

Das sieht der *USER* bei vdradmind auch nicht. Für den User ist das eine Blackbox.
Die Blackbox die ich gedenke aufzubauen wird aber Schritt für Schritt in ihrer Entstehung dokumentiert.

Hi

der Teil 4 des Entwicklunstagebuchs ist jetzt online und kann unter [URL=http://maniac.rz.tu-ilmenau.de/schrankmonster/PermaLink,guid,2a6ce96d-8684-4c1d-b3ba-f96866afc617.aspx]hier bestaunt [/URL]werden.

Kommentare und Vorschläge nehme ich immer gerne auf.