Eine Verlagerung der getUniqueId() aus der 99_Utils.pm in die fhem.pl den Vorteil, dass man sich als Modulentwickler auf die Verfügbarkeit der Funktion besser verlassen kann.
Die Erfahrung zeigt, dass es immer wieder Anwender gibt, die die 99_Utils.pm durch "eigene" Inhalte ersetzen, womit die Funktion dann (bis zum nächsten Update der Datei) nicht mehr verfügbar ist.
Wenn das eine zentrale Funktion wird, kann ich auch die datenbanksystemabhängige Generierung von uuid aus der configDB ausbauen.
Bist Du sicher, dass das ein Problem ist?
Ich frage mich, ob dann die anderen Funktionen aus Utils.pm nicht genauso ins fhem.pl wandern sollten, die gleichen Argumente gelten ja fuer die doch auch. 99_Utils.pm wuerde ich dann loeschen. Alternativ wird aus 99_Utils.pm ein Utils.pm, und fhem.pl laedt diese Datei explizit, in der Hoffnung, dass man sich da weniger drantraut.
Evtl. reicht auch das Entfernen von 99_Utils.pm aus der "Edit Files" Liste, bzw. das Ersetzen durch ein "99_myUtilsTemplate.pm"
Meinungen?
Zitat von: rudolfkoenig am 11 Januar 2015, 14:05:29
Bist Du sicher, dass das ein Problem ist?
Naja, der Fall kam schon mehrfach vor.
Als Modulentwickler habe ich mich aus diesem Grund bisher gescheut, in 99_Utils.pm vorhandene Funktionen in meinen Modulen zu verwenden. Die getUniqueId() ist für mich jetzt der erste Fall, den ich gerne in Modulen verwenden würde - im Gegensatz zu anderen Funktionen in dieser Datei. Es wird immer Funktionen geben, die "nett" sind und in die 99_Utils.pm gehören, aber für mich persönlich gibt es da durchaus auch noch eine Unterscheidung zwischen "sinnvoll (zentral) nutzbar" und "nice to have".
Da ich das relativ entspannt sehe, und z.Zt. keinen zusaetzlichen Diskussionsbedarf habe, habe ich es einfach gemacht und eingecheckt. D.h. getUniqueId/getKeyValue/setKeyValue sind vom 99_Utils.pm nach fhem.pl gewandert.
Danke.
Und nun musste ich feststellen, dass ich in meinem (nicht mehr ganz) jugendlichen Leichtsinn :-[ völlig übersehen hatte, dass getUniqueId() gar nicht das tut, wovon ich ausgegangen war - nämlich bei jedem Aufruf eine neue uid zurückzuliefern. Dazu bedarf es eher einer Funktion createUniqueId() deren Einbau ich mit folgendem Patch vorschlage.
Index: fhem.pl
===================================================================
--- fhem.pl (Revision 7536)
+++ fhem.pl (Arbeitskopie)
@@ -100,6 +100,7 @@
sub concatc($$$);
sub configDBUsed();
sub createNtfyHash();
+sub createUniqueId();
sub devspec2array($);
sub doGlobalDef($);
sub escapeLogLine($);
@@ -111,6 +112,7 @@
sub getAllAttr($);
sub getAllGets($);
sub getAllSets($);
+sub getUniqueId();
sub latin1ToUtf8($);
sub myrename($$);
sub notifyRegexpChanged($$);
@@ -4009,9 +4011,17 @@
{
my ($err, $uniqueID) = getKeyValue("uniqueID");
return $uniqueID if(defined($uniqueID));
+ my ($uniqueID) = createUniqueId();
+ setKeyValue("uniqueID", $uniqueID);
+ return $uniqueID;
+}
+
+sub
+createUniqueId()
+{
+ my $uniqueID;
srand(time);
$uniqueID = join "",map { unpack "H*", chr(rand(256)) } 1..16;
- setKeyValue("uniqueID", $uniqueID);
return $uniqueID;
}
createUniqueId() taugt so nicht, siehe:
{ Log 1, createUniqueId();;Log 1, createUniqueId();;Log 1, createUniqueId();;Log 1, createUniqueId();; }
Hab eine angepasste Version eingecheckt.
Dankeschön, funktioniert in meiner Testumgebung prima.
Wieder ein spürbarer Performancegewinn und ein Stück Vereinheitlichung.
Zitat von: rudolfkoenig am 11 Januar 2015, 14:05:29
Evtl. reicht auch das Entfernen von 99_Utils.pm aus der "Edit Files" Liste
...
Meinungen?
Fände ich gut :)
Zeile 1462: push(@ret, $f) unless $f eq '99_Utils.pm';In der configDB habe ich das (auf meinem Testsystem) schon analog ausgebaut.
(http://up.picr.de/20674236ny.png)
Ich habe myUtilsTemplte.pm hinzugefuegt, und 99_Utils.pm aus der Liste entfernt.
super :)
Zitat von: rudolfkoenig am 11 Januar 2015, 14:05:29
Bist Du sicher, dass das ein Problem ist?
q.e.d.
http://forum.fhem.de/index.php/topic,32555.msg249521.html#msg249521
Jaja, das Aendern der 99_Utils.pm wird mit der aktuellen Version nicht mehr ermutigt.