xml-rpc

[Crimson]

Hallo,
da ich nichts darüber gefunden habe würde ich gerne wissen/vorschlagen das xml-rpc integriert wird um etwaigen desktop tools eine gute schnittstelle zu liefern

Greetz,
Crimson

[xsign.dll]

Was verstehst du unter "etwaigen Desktop Tools" ?

Prinzipiell kann man sicherlich auch mit Desktop Tools ganz stink normale Requests absetzen, doch die XML Funktionalität wäre natürlich interessant. Derzeit ist noch nichts vorgesehen, aber ich hau es vorsichtshalber mit in die ToDo Liste.

Welche Klasse wird denn davon gewünscht? PEAR oder die Standalone? Oder gar eincompiliert (was in unserem Fall weniger wünschenswert ist)?

[Jens-A. Koch]

Hallo Crimson,

herzlich Willkommen im Board. Dein Vorschlag Webservices einzubauen ist eine gute Idee!
Die anschließende Frage ist dann, für welche Module eine solche Schnittstelle bestehen soll.
Was stellst du dir da genau vor? Also für das News-Modul könnte man derartiges leicht realisieren, wenn man sich mal für eine Class entschieden hat.

Ich nehme an mit "Desktop Tools" meinst du Applikationen wie Blog-Writer oder Editoren.
Hast du dabei an irgendein spezielles Tool gedacht?

Neben XML-RPC kommt auch SOAP für einen solchen Webservice in Betracht. Das würde mir fast noch besser gefallen. Generell dürfte ersteres einfacher sein, letzteres aber für unsere Arraystrukturen wohl besser. Ist aber auch gehuppt wie gesprungen, denn die XML-Strukturen kann man ja mit XSLT beliebig umtransformieren.

Grüße Jens
---
zu xml-rpc
Eincompilieren ist keine gangbare Idee für die Umsetzung, wie schon von xsign.dll festgestellt.
http://www.xmlrpc.com/directory/1568/implementations listet ja zahlreiche PHP-Implementierungen auf.
Kurz zusammengefasst bleiben:
http://keithdevens.com/software/xmlrpc
http://sourceforge.net/projects/phprpc/
http://scripts.incutio.com/xmlrpc/
http://simplexmlrpc.sourceforge.net/ php4
und natürlich 2xPEAR
http://pear.php.net/manual/en/package.webservices.xml-rpc.php

PHP5 only http://pear.php.net/manual/en/package.webservices.xml-rpc2.php
Der Klick auf die Docu für die Serverschnittstelle führt zur fast schon screenshotwürdigen Aussage: "to be written". Schönen Dank auch

[xsign.dll]

Nur vorab (da ich schon kurz mit ihm geredet hatte): Er meinte nen Admin Interface Was mich natürlich auch ein wenig grübeln lässt, ist, wie hoch der Arbeitsaufwand für so eine xml-rpc implementation ist. Es müsste ja schlichtweg fast für jedes Modul eine XML-RPC Schnittstelle gegeben sein. Gut, letztlich beläuft es sich hauptsächlich ja auf Datenbank Anbindung - soll heißen: wir schreiben die XML-RPC Funktionen so, dass eben die DB gequeried wird für dass jeweilige Modul.

Könnte nen ganzschöner Brocken werden...

[Crimson]

hat ja keiner gesagt das ihr das alleine machen müsst
ich würde bei den Schnittstellen natürlich mithelfen soweit es meine zeit zulässt
klar erstmal wär es nur sinnvoll relativ einfache module (news, artikel ,links u.ä.) und natürlich die die Settings mit einer Schnittstelle zu versehen da es sich nicht lohnt in so einem frühen Stadium schon so viel Aufwand in solche eine "spielerei" zu stecken
aber es spricht ja nichts dagegen die Schnittstellen für andere Module "nachzurüsten"

[xsign.dll]

Wie sieht das mit Cookies aus Kannst du die über deine GUI verarbeiten? Die wären zumindest fürs erste wichtig für die Authentifizierung - ansonsten müsste man es über ne Session ID regeln, was zwar geht und auch unterstützt wird, aber zumindest von mir nicht bevorzugt wird.

[Crimson]

cookies zu verarbeiten ist kein Problem das geht schon

[Jens-A. Koch]

  - Der Feature Request entpuppt sich als handfestes Bewerbungsgespräch.
Du kannst uns sehr gern bei der Umsetzung unterstützen, Crimson.
-

Externes "Admin Interface"? Demnach soll die gesamte Anwendung von außen mittels Webservice administrierbar sein? Das geht etwas über ne einfache Syndication oder ne BloggerApi hinaus.

Zur Service Architektur: wenn das gesamte AdminInterface abgebildet werden soll, dann könnte man jeder Modulmethode den jetztigen Ausgabe-Schritt abziehen, für den Fall das ein Webservice das Modul anspricht.

Bis zum Ausgabepunkt wären die Requests identisch ( Filter und Typcheck für Get/Post + Security + Login).  Die Unterscheidung könnte dann mittels einer Trigger-Variable (zB $this->modul_as_webservice) erfolgen. So kann man daran festmachen, ob die Daten an Smarty assigned oder an den Webservice-Handler (wie er nun aussehen mag) übergeben werden sollen. Simpel gesagt: ne Eingabe/Ausgabe-Weiche. Das ist dann nicht unbedingt ein ganz so großer Brocken.

Abgesehn von der Schnittstelle bleibt die Frage, wie der Client bzw. dieses Tool aussehen soll.
Falls es den Client in der Art nicht gibt, wäre die Erstellung eher etwas für
FF-XUL Enthusiasten oder C++ Coder.

[Crimson]

gerne
aber beschwert euch nicht wenn ich nicht viel zeit habe --> Ausbildung zum fachinformatiker für Anwendungsentwicklung^^ sprich ganzen tag auf der arbeit am proggen da habe ich auch mal meine Durchhänger und habe keinen bock aufs proggen
mal abgesehen davon das ich ab und zu auch noch was anderes mache

zu dem client
so einen gibts meines wissen noch nicht.
aber ich bin gerade einen am entwickeln
aber net als firefox extension oder c++
ich bin eher für c#

[xsign.dll]

Na es ist vorallem wichtig , dass so ein Tool auch "nützlich" für Admins/User ist. Schließlich muss es einen gewissen "Geschwindigkeitsvorteil" geben.

[Crimson]

nuja die geschwindigkeit hängt ja zu guter letzt an dem server wo das cms installiert ist
aber schon alleine durch die Menüs ist man um einiges schneller durch
da die daten nicht bei jedem Aufruf eines menüs sondere einmal beim start und dann alle xx minuten vom server geladen werden sollen.
so fällt schonmal das laden der webseite selber weg zumindest für eine bestimmte zeitspanne
mal von features wie "seiten profile" etc. ganz abgesehen.
die würde die Administration der Webseite auch wieder um einiges einfacher machen.
ne genauere beschreibung wie ich mir das Programm vorstelle kann ich euch demnächst zeigen.
ich muss meine Konzeption etc. erstmal aktualisieren und ordnen sonst kann man die niemandem zumuten

[Jens-A. Koch]

aber beschwert euch nicht wenn ich nicht viel zeit habe --> Ausbildung zum fachinformatiker für Anwendungsentwicklung^^ sprich ganzen tag auf der arbeit am proggen da habe ich auch mal meine Durchhänger und habe keinen bock aufs proggen
mal abgesehen davon das ich ab und zu auch noch was anderes mache

Kein Problem, es ist ein Hobbyprojekt - auch für uns. Dich wird also niemand mit dem Pflichtenbuch schlagen

Auf die Ansätze zum C#-Client bin ich gespannt, denn allein fürs Debugging, wäre er von Anfang an nützlich.

[Crimson]

ich werde euch dann sobald ich den core soweit habe das man ihn nutzen kann eine Version zukommen lassen.
aber auf die gui müsst ihr dann noch verzichten^^
console ftw 
(je nachdem wie schnell ich jetzt voran komme kann es sich noch gut um min. 2-4 wochen handeln)

[xsign.dll]

machs in java *G

ne quatsch - aber vain hat schon recht. wir prüglen entwickler nicht - wir prügeln uns meist nur gegenseitig wenns um Variablen, Konstanten und Konventionen geht

[Crimson]

ich kann java nicht ab^^
alles schon angetestet und c# hat mir bisher am besten gefallen, frag mich nicht wieso ich kanns mir auch nicht erklären ^^

solche projekte sind mir am liebsten
ohne zwang und sinn freien leistungsdruck

[xsign.dll]

Ach java is ganz schön - wenn auch strikt. Azureus z.b. ist komplett java. Von daher find ichs echt nicht schlecht...

[Crimson]

joa
son großer unterschied ist da ja auch wieder nicht zwischen java und csharp aber wie schon gesagt mir gefällt c# besser
ich hätte auch noch andere Ideen für Desktop Tools z.b. nen user controll center . aber ich denke die Ideen sind am Anfang nicht so Wichtig letztendlich ist es ja der Admin der entscheidet welches CMS benutzt wird also muss man ihm das ja erstmal schmackhaft machen

[Jens-A. Koch]

wäre es möglich, die libraries so zu wählen, dass man den client auch unter linux laufen lassen kann. wxwidgets oder ähnlich?

[Crimson]

hatte ich vorerst nicht geplant, da die gui aber sowieso in einer eigenen dll steckt ist die leicht austauschbar.
ich habe auch fürs erste nicht vor für linux zu entwickeln deswegen weiss ich auch nicht wie weit es mit der kompatiblität von mono zu meinen Komponenten aussieht, mono ist ja leider keine 1 zu 1 portierung vom .net framework bzw. die funktionen verhalten sich teilweise doch schon anders.
falls der kern an sich mit mono läuft spricht ja nichts dagegen mehrer gui´s anzulegen bzw. bereitzustellen

[Jens-A. Koch]

mit mono sollte ne plattformunabhängigkeit eigentlich kein problem werden, wenn die abhängikeiten nicht sehr speziell sind. aber mach erstmal nen prototypen.

meine phplibrary-wahl ist vorerst auf php-xmlrpc (http://phpxmlrpc.sourceforge.net/) gefallen.