UPEK Vertreibt seine Software jedoch ausschließlich über OEMs. Da Dell keine aktuelle Version hat, habe ich einfach mal bei Lenovo geschaut. Und siehe da: UPEK ProtectorSuite QL 5.8 mit 64Bit Unterstützung:

Windows Vista x64
http://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/fprx64_584_5476ww.exe

Windows Vista x86 und XP
http://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/fprx32_584_5476ww.exe

Eine Extension für Firefox 3.5, die mit der Protector Suite QL kommuniziert kann unter folgendem Link heruntergeladen werden:

http://files.upek.com/GetPackage.asp?Key=T3L211M1FJS1ORDL02KC3696DM4V21PI

Ich habe die Software auf einem Dell XPS1330 Notebook mit Vista x64 installiert und es funktioniert einwandfrei!

1. Folgenden Codeschnipsel  in der comments.php hinzuefügt
   1. <?php if (function_exists(‘get_avatar’)): ?>
   2. <?php echo get_avatar($comment, 48); ?>
   3. <?php endif; ?>
2. Das Stylesheet um die .avatar Klasse erweitert
   1. .avatar{
   2.   float: right;
   3.   margin: 3px 0 15px 10px;
   4.   border: 1px solid #333;
   5. }

That’s it! Die ausführliche Doku zur Funktion get_avatar() ist hier nachzulesen.

Vista Rechner in einer Windows 2003 Domäne sind eine Qual – man findet immer wieder neue Hindernisse. Bei aktivierter UAC z.B. sind per Login-Script gemappte Netzlaufwerke für nicht-administrative Benutzer auf einem Vista Computer unsichtbar. Das Phänomen tritt jedoch lediglich bei Skripten auf, die über Gruppenrichtlinien verteilt werden. ..

Microsoft begründet dieses Verhalten wir folgt:

UAC may prevent Group Policy logon scripts from appearing to work properly. For example, a domain environment contains a GPO that includes a logon script to map network drives. A nonadministrative user logs on to the domain from a Windows Vista computer. After Windows Vista loads the desktop, the nonadministrative user starts Windows Explorer. The user sees their mapped drives. Under the same environment, an administrative user logs on to the domain from a Windows Vista computer. After Windows Vista loads the desktop, the administrative user starts Windows Explorer. The user does not see their mapped drives.

When the administrative user logs on, Windows processes the logon scripts using the elevated token. The script actually works and maps the drive. However, Windows blocks the view of the mapped network drives because the desktop uses the limited token while the drives were mapped using the elevated token.

(Quelle http://technet.microsoft.com/en-us/library/cc766208%28WS.10%29.aspx)

Kurz zusammengefasst: Die GPO wird in einer Sitzung mit erhöhten Rechten verarbeitet. Der Explorer-Prozess des Benutzers läuft in der Sitzung mit eingeschränkten Rechten und ’sieht’ die gemappten Laufwerke nicht.

Also falls es Probleme mit Netzlaufwerken auf Vista Rechenrn gibt, prüfen ob die Login-Skripte richtig ausgeführt werden und ggf die UAC ausschalten.

Kann die UAC aus Sicherheitsgründen nicht ausgeschaltet werden, so soll laut [LINK] auch folgender Registry-Wert das Problem beheben:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections =(dword)1

Ich hatte bislang noch keine Möglichkeit das zu testen, gescheige denn zu recherchieren was der Wert macht, werde es aber ASAP nachholen!

P.S.: In einer 2008 Domäne können Netzlaufwerke übrigens ohne Skript per GPO gemappt werden, dort tritt dieser Effekt nicht auf.

Im Auslieferungszustand braucht die App auf einem iPhone 3G je nach Verbindungsgeschwindigkeit bis zu 20 Sekunden zum starten. Jeder Admin sagt: Ist doch akzeptabel für einen online Zugriff, schließlich muss alles erst übertragen werden. Leider sieht das der Benutzer anders: 20 Sekunden sind zu lang um während eines Telefonates “mal eben” einen Termin zu finden. Natürlich kann man darüber streiten, aber ich kann die Beschwerden der Benutzer verstehen. Für “mal eben” 20 Sekunden zu lang.

Mit einigen einfachen Optimierungen lässt sich die Startzeit jedoch verkürzen. Die App braucht umso länger, je mehr Einträge aktualisiert werden müssen. Deswegen sollte man entweder den Ticker oder den Eingang automatisch aktualisieren lassen. Wird beides aktiviert, werden Daten redundant geladen und die App braucht länger. Wen ohnehin nur der Eingang interessiert kann den Ticker abschalten. Zudem empfiehlt es sich die Anzahl der zu aktualisierenden Einträge zu reduzieren. Bei deaktiviertem Ticker und 5 automatisch geladenen Mails verkürzt sich die Startseit auf ca 8 Sekunden. Entfernt man in der Konfiguration noch den zusätzlichen Port 81 kann man weitere 2 Sekunden einsparen.

So sind in meinen Augen 6 Sekunden Startzeit etwas alltagstauglicher als die anfänglichen 20 Sekunden, aber immer noch micht genug Kommentare mit weiteren Tipps sind herzlich willkommen!

Aber dafür ist ja die Hotline da, die macht das schon -  denkste! Die sind nur bis 20:00Uhr da und es war gerade 20:02Uhr als ich angerufen habe. Zum Glück bin ich nicht der Einzige, der auf einem Strato-Server *.php Dateien standardmäßig mit PHP5 ausführen will. Der .htaccess Befehl, den die  Jungs von Scrpit Artists gebloggt haben funktioniert zum Glück auch auf Managed Servern. Gott seid Dank, denn bei Managed Servern fehlt der Eintrag im Kundenmenü!

Folgende Zeile in der .htaccess setzt PHP5 als default für *.php-Dateien:

AddType application/x-httpd-php5 .php


So, Abend/Nacht gerettet, bin dann mal wieder Server einrichten…

Bild1

Als Hobbyfotograf nutze ich zur Bildbearbeitung das Wacom Bamboo Tablet. Ein großartiges Gerät was zuverlässig seinen Zweck erfüllt und dabei noch relativ günstig in der Anschaffung war.

Merkwürdig ist nur, dass der Stiftdruck unter Vista nicht so richtig will. Hat man den Bamboo-Treiber frisch installiert funktionier der Stiftdruck bis zum nächsen Neustart. Es scheint, dass der Vista “Tablet PC-Eingabedienst” was damit zu tun hat. Dieser Dienst wird beim booten von Vista automatisch gestartet sobalt ein Tablet installiert ist. Aufgefallen ist mir dieses Problem in Photoshop, andere Anwendungen habe ich nicht getestet.

Bild2

Das Problem lässt sich jedoch beheben, indem man den Windows-Dienst “Tablet PC-Eingabedienst” beendet und deaktiviert. In der Windows Diensteverwaltung (Start->Ausführen->’services.msc’ eingeben oder Windowstaste+R->’services.msc’ eingeben) die Eigenschaften des Dienstes “Tablet PC-Eingabedienst” aufrufen (Siehe Bild1). In den Eigenschaften den Dienst zuwerst beenden und dann die Startart auf deaktiviert setzten (Bild2). Mir hat’s geholfen!

Wenn es in PHP-Projekten um Client-Server-Kommunikation, ins Besondere um RPC, geht, lässt man sich schnell dazu verleiten “mal eben” was eigenes zu bauen, obwohl es doch einige Standards für RPC gibt. Viele – genau wie ich auch – scheuen den Aufwand sich in Monster wie SOAP oder das etwas schlankere XML-RPC einzuarbeiten. Mit den richtigen Tool’s jedoch können PHP-Klassen jedoch mit geringstem Mehraufwand über SOAP zugänglich gemacht werden.

PHP mit aktiviertem SOAP

Die Einzige Vorraussetzung ist einen Webserver mit PHP5.0.3 oder aktueller und aktiviertem SOAP.

Leider ist die native SOAP-Implementation von PHP jedoch relativ kryptisch und bietet momentan keine Möglichkeit WSDL Dateien zu generieren.  Die Web Services Description Language ist eine plattform-, programmiersprachen- und protokollunabhängige Beschreibungssprache für Netzwerkdienste (Web Services) zum Austausch von Nachrichten auf Basis von XML. Über diese WSDL-Dateien können dann Client-Stubs, z.B. in .NET komplett generiert werden.

Abhilfe schafft da der Webservice-Helper [nachfolgend WSH genannt] von jool.nl. Der WSH nimmt einem jegliche Arbeit ab, um Klassen und Objekte über SOAP bereitzustellen.Zusätzlich generiert der WSH automatisch WSDL-Dateien. Diese WSDL’s können dann, wie gesagt zum generieren von Clients in beliebigen Sprachen benutzt werden.

Also den WSH herunterladen und entpacken. Standardmäßig kann der WSH auf Klassen zugreifen die in den folgenden Unterordnern liegen:

• lib/data_objects/Klassenname.class.php
• lib/soap/Klassenname.class.php
• lib/Klassenname.class.php

Der Dateiname muss sich aus dem Klassennamen und “.class.php” zusammensetzten. Es ist jedoch auch möglich, Klassen aus anderen Ordnern bereitzusetellen. Dazu muss die Autoload-Funktion in der common.php angepasst  werden.

Die dort definierten Suchpfade und auch Dateinamen (.class.php) können nach belieben geändert werden. Ist der Zugriff konfiguriert, müssen die Klassen noch in der config.php freigegeben werden.

config.php

Alle Klassen, die über SOAP betreitgestellt werden sollen müssen im Array $WSClasses aufgeführt werden. Damit wird sichergestellt, dass über die autoload Funktion keine ungewollten Dateien aufgerufen werden. Objekte bzw. strukturierte Datentypen, die als Paramer oder Rückgabewert einer Funktion genutzt werden, sollten noch im Array $WSStructures aufgeführt werden, damit man einen typisierten Austausch dieser Daten realisieren kann.

Typisierte Daten in PHP?! Ja genau. Damit die ganze Geschichte funktioniert muss der PHP Code Dokumentiert/Typisiert werden. Die Syntax der Dokumentation ist analog der von phpDocumentor, jedoch wird nur ein Teil der Schlüsselwörter benutzt. Jeder Parameter und der Rückgabewert einer Methode muss Typisiert werden. Das geschieht durch die Schlüsselwörter @param und @return um Doc-Block (/**  */). Dazu ein kleines Beispiel:

BeispielKlasse.class.php

TestDatentyp.class.php

Sind alle Klassen geschrieben ist der WebService fertig. Denn der WSH sorgt nun dafür, dass alle Methoden, die public sind, über SOAP bereit gestellt werden. Die passende WSDL zum WebService gibts automatisch dazu. Unter folgendem Pfad kann man die WDSL beziehen:

http://deinserver/service.php?class=BeispielKlasse&wsdl

Mit dieser WSDL-Datei kann man nun auf einfachste Weise Client-Stubs generieren. Ein Tutorial dazu werde ich die Tage mal verfassen.

Bei der Arbeit mit diesem PHP WebService wird man auf zwei größere Hürden stoßen:

1. Persistenz
2. Codeänderungen

Zu 1: Die PHP-SOAP-Engine kennt zwei Persistenz-Modi: SOAP_PERSISTENCE_SESSION und SOAP_PERSISTENCE_REQUEST. Der SOAP_PERSISTENCE_SESSION-Modus ist der schönere von beiden , PHP-Objekte werden mit all Ihren Attributen in einer Session gespeichert und sind somit über mehrere Aufrufe persistent. Da PHP Cookies nutzt um die Session-ID an den Client zu übermitteln, muss sichergestellt sein, dass der SOAP-Client dies auch unterstützt.
Der SOAP_PERSISTENCE_REQUEST-Modus hingegen deaktiviert die Persistenz und versetzt den WebService in den Amnesie-Modus
Leider ist die Persistenz im WSH standardmäßig deaktiviert. Um die szu ändern muss folgende Codezeile in der service.php ersetzt werden:

ersetzten durch

Zu 2: Damit die ganze WebService Sache einigermaßen performant bleibt, arbeiten sowohl der WSH alsauch die nativen PHP-Methoden mit Caches. Damit äußere Strukturänderungen an den über SOAP bereitgestellten Klassen angewandt werdem müssen der WSDL-Cache und der PHP-Cache gelöscht werden. Die WSDL-Dateien befinden sich im Unterordner ‘wsdl’ vom WSH. Bei geändertem Code einfach alle Datien löschen, damit diese neu generiert werden können. Dazu sollte man noch den WSDL-Cache von PHP löschen. Dieser befindet sich im tmp-Ordner des Servers (/tmp). Alle Dateien die mit ‘wsdl-’ beginnen löschen – dann klappts auch mit den Änderungen

In diesem Sinne, viel Erfolg. Fragen bitte als Kommentar posten!

Code:
sudo loadkeys de
sudo /etc/init.d/console-setup start


Have fun changing keymaps