Gerade eben dachte ich mir, ich könnte mal wieder meinen Zugang zum BW-Grid richtig einrichten, da wurde demletzt nämlich der Headnode geändert. Also die E-Mail mit dem neuen Hostnamen gesucht, Zertifikat runtergeladen, mit OpenSSL gehashed, passend kopiert, signing policy erstellt… und nix geht, wie immer.

Dass das OpenSSL-Geblödel immer so umständlich sein muss… eine halbe Stunde später habe ich es dann, doch noch hin bekommen – das Root-Zertifikat musste ich auch noch neu runterladen, hashen und die signing policy dafür erstellen. Hauptsache, es geht, gerade eben bin ich erfolgreich auf dem Headnode eingeloggt.

Ich hasse es, wenn mir Computer Vorschriften machen, wie ich mich zu verhalten habe. Lange Zeit bin ich da gar nicht dahinter gekommen, ich dachte es wäre ein Fehler im Firefox, dass ich zum Beispiel bei der Commerzbank mein Passwort nicht speichern kann. Als mir das gleiche aber beim Kicker Managerspiel passierte, wurde ich doch stutzig, denn bei einer Bank mag so was, wie auch immer realisiert, noch Sinn machen, beim Kicker sicherlich nicht.

Gewundert und informiert und was musste ich herausfinden? Es gibt die Möglichkeit, dass der Autor einer Seite das Speichern von Formulareingaben von vornherein unterbindet:

Gibt ein Benutzer seinen Benutzernamen und ein Passwort ein, bieten einige Browser die Funktion, beide Feldinhalte zu speichern. Grundsätzlich steht es dem Benutzer frei, das Speichern anzunehmen oder abzulehnen. Allerdings gibt es Situationen, in denen es sinnvoll sein kann, diese Freiheiten zu beschneiden und AutoComplete bereits von Seiten des Autors zu unterbinden. Dazu wurde in einigen Browsern die Unterstützung des nicht standardisierten Attributs autocomplete implementiert. AutoComplete kann verhindern, dass Daten gespeichert und bei der nächsten Verwendung automatisch vervollständigt werden. (Quelle: selfhtml.de)

Total bescheuert, aber man kann’s ausschalten – immerhin.

Über den Wikipedia-Artikel über Prosa bin ich auch einen Bericht von Emil Zopfi über die ebenfalls PROSA (“Programmieren mit Symbolischen Adressen”) genannte Programmiersprache von Siemens gestoßen. Echt interessant, auch wenn das damalige Vorgehen einem heute natürlich wie aus der Steinzeit vorkommt:

Man soll jetzt nicht denken, wir hätten die PROSA-Programmtexte direkt auf Lochstreifen geknipst. Wir programmierten weitgehend im Kopf, zeichneten Flussdiagramme mit Schablone, schrieben den Code in sauberen Druckbuchstaben in Programmformulare, Null immer durchgestrichen zur Unterscheidung von O, schickten die Formulare in die Locherei zu den flinken Locherinnen, bekamen nach ein paar Tagen die gestanzten Karten, lieferten sie in die Programmübersetzung, erhielten nach einem oder zwei Tagen eine gedruckte Liste, meist voller Fehlermeldungen, und einen Lochstreifen mit dem Maschinencode. So ging alles seinen geordneten Lauf. Korrigieren, fehlerhafte Karten ersetzen, nochmals übersetzen, dann Rechenzeit buchen auf einem Testrechner ­ wie bitte? Eine Stunde am Sonntag morgen zwischen drei und vier Uhr? Hart war das Leben.
(aus Emil Zopfi – Prozessrechnerprosa)

Ganz spontan habe ich mich letztens dann doch entschlossen, mir eine PS3 zu kaufen. Die PS2 ist zwar noch gut, aber was soll’s, das Geld muss ja weg bevor’s nichts mehr wert ist.

Da meine Spiele noch nicht gekommen sind – ebensowenig wie das HDMI-Kabel, und das Kabel , dass ich habe, passt natürlich nicht -, habe ich gerade erstmal Linux drauf gebügelt. Leider kann die Festplatte nur 70GB/10GB (oder eben 10GB/70GB) zwischen Playstation OS und Linux aufteilen, aber ich denke 10GB genügen erstmal. Und die Installation ging auch deutlich einfacher als damals auf der PS2 – nix mehr mit Memory Card und Festplattenadapter-Käse, ist ja alles schon integriert. Mal sehen was man mit so einem PPC 64 tolles anstellen kann…

Schon lange gab’s keine Berichte mehr zum Thema “Spaß mit Web Services”, heute ist es mal wieder soweit. Ich habe jetzt kaum einen kompletten Arbeitstag mit einem Problem verschwendet, dass sich mal wieder als äußerst trivial darstellt – ein einziges Attribut in der XML Schema-Definition passend gesetzt und alles geht, ansonsten geht halt nichts.

Kurz zum Hintergrund: ich versuche gerade, einen WS-Agreement Web Service von GT4 auf UNICORE/WSRFLite zu portieren und darüber einen Artikel zu schreiben. Das hat bis gestern auch alles funktioniert, nur habe ich dann festgestellt, dass ich keine Attribute setzen kann, ohne dass es knallt: “Unbound namespace URI ‘http://schemas.ggf.org/graap/2007/03/ws-agreement’” ist die wenig aussagekräftige Fehlermeldung.

Gut, dachte ich mir, vielleicht geht, warum auch immer, nur dieses eine Attribut nicht, also ein anderes gesetzt – nichts. Es lagen auch keinen alten Bibliotheken irgendwo rum, also sehr komisch. “Definierst du dir halt eigenes Element mit Attribut, vielleicht geht’s dann”, dachte ich mir – half aber auch nichts. Also nochmal an den WSRFLite-Beispielservice, dort ein Element um ein Attribut erweitern und testen – geht. Äh, wie jetzt nochmal? Dann habe ich mal mein eigenes Element in eine eigene Schema-Datei extrahiert und auch das ging. Beim vergleichen meiner Schema-Datei mit der von WS-Agreement ist mir dann aufgefallen, dass bei WS-Agreement »attributeFormDefault=”qualified”« gesetzt ist, in meinem Schema aber nicht. Und, oh Wunder, als ich dies entfernt habe, ging’s auf ein Mal.

Mir ist allerdings im Moment nicht klar, wo genau das Problem liegt. Möglicherweise liegt es an der WSRFLite (respektive XFire)-Version, vielleicht auch an der Kombination von »elementFormDefault« (“qualified” bei WS-Agreement) und »attributeFormDefault« (“auch qualified”). Wenn ich dazu noch Muse habe – immer eher unwahrscheinlich, wenn das initiale Problem gelöst ist, aber vielleicht doch, da ich ja immer gerne weiß, warum etwas nicht ging -, werde ich mal untersuchen, wie sich die verschiedenen Kombinationen auswirken; bei Oracle gibt’s zu diesem Thema ein nettes Dokument, XML Schema: Understanding Namespaces.