Originally posted by: <email address deleted>
Gibt es eine Möglichkeit dem fhem zu sagen, dass ich - beispielsweise die
xmllist oder jsonlist - komprimiert zurückhaben will? (i.e. via .gzip) Und
falls das geht: was muss ich dafür tun?
andy
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
On Wed, Jan 06, 2010 at 11:11:49PM +0100, Andy Fuchs wrote:
> Gibt es eine Möglichkeit dem fhem zu sagen, dass ich - beispielsweise die
> xmllist oder jsonlist - komprimiert zurückhaben will? (i.e. via .gzip)
Noe. Man koennte vor "return $str" sowas einfuegen wie:
if($attr{global}{json_compress}) {
use Compress::Zlib;
$str = Compress::Zlib::memGzip($str);
}
Und in JsonList_Initialize muesste noch $modules{_internal_}{AttrList} um
json_compress erweitert werden.
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Wäre das nicht eine schöne *generelle* Erweiterung. Das ist gerade für
remote-access hilfreich (vor allem, wenn die Setups umfangreicher sind).
a.
On 07.01.10 08:24, "Rudolf Koenig" wrote:
> On Wed, Jan 06, 2010 at 11:11:49PM +0100, Andy Fuchs wrote:
>> Gibt es eine Möglichkeit dem fhem zu sagen, dass ich - beispielsweise die
>> xmllist oder jsonlist - komprimiert zurückhaben will? (i.e. via .gzip)
>
> Noe. Man koennte vor "return $str" sowas einfuegen wie:
>
> if($attr{global}{json_compress}) {
> use Compress::Zlib;
> $str = Compress::Zlib::memGzip($str);
> }
>
> Und in JsonList_Initialize muesste noch $modules{_internal_}{AttrList} um
> json_compress erweitert werden.
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Andy Fuchs wrote:
> Wäre das nicht eine schöne *generelle* Erweiterung. Das ist gerade für
> remote-access hilfreich (vor allem, wenn die Setups umfangreicher sind).
Die alte Leier, Overhead Komprimierung+Dekomprimierung vs. Bandbreite ;)
Über welches Netz meinst Du denn, auf FHEM zuzugreifen, daß es relevant
ist, hier zu komprimieren? (Ernstgemeinte Frage; xmllist o. ä., also FHEM-
interna, ruft doch niemand per GSM oder HCD auf; einzig für pgm2 wäre das
imho relevant -- und mit Apache-Wrapping auch zu erschlagen?)
Denke ich an schwachbrüstige Kisten wie die NSLU2, düfte der Mehraufwand
für die serverseitige Komprimierung schon ins Gewicht fallen? Und bei Sheeva
& GBit-Ethernet würde ich jedenfalls erwarten, daß unkomprimierte Übertra-
gung schneller ist als Komprimierung+Übertragung -- Meßwerte wäre aber mal
interessant ;)
kai
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
On 07.01.10 10:46, "Kai 'wusel' Siering" wrote:
> Andy Fuchs wrote:
>> Wäre das nicht eine schöne *generelle* Erweiterung. Das ist gerade für
>> remote-access hilfreich (vor allem, wenn die Setups umfangreicher sind).
>
> Die alte Leier, Overhead Komprimierung+Dekomprimierung vs. Bandbreite ;)
> Über welches Netz meinst Du denn, auf FHEM zuzugreifen, daß es relevant
> ist, hier zu komprimieren?
EDGE
> (Ernstgemeinte Frage; xmllist o. ä., also FHEM-
> interna, ruft doch niemand per GSM oder HCD auf; einzig für pgm2 wäre das
> imho relevant -- und mit Apache-Wrapping auch zu erschlagen?)
Bin ich anderer Meinung. Wozu baue ich mir ein remote-fähiges
Heim-Automatisierungs-System und eine Software für's iPhone/Android, wenn
ich es dann nur von zuhause benutze??? Das wäre blöd.
Sicher wäre es auch nicht schlecht, zusätzlich eine Software für mobile
Devices zu haben, die nur die tatsächlich benötigten Daten schickt/empfängt.
Dazu müsste ich aber dann auf dem Server noch PHP laufen lassen (was hier
schon als Overhead empfunden wurde), oder so eine Erweiterung als Perl zu
implementieren, wozu ich mich derzeit nicht bereit fühle (und in Zukunft
wohl eher auch nicht - aber vielleicht ist ja jemand käuflich und macht mir
das dann :-))
> Denke ich an schwachbrüstige Kisten wie die NSLU2, düfte der Mehraufwand
> für die serverseitige Komprimierung schon ins Gewicht fallen? Und bei Sheeva
> & GBit-Ethernet würde ich jedenfalls erwarten, daß unkomprimierte Übertra-
> gung schneller ist als Komprimierung+Übertragung -- Meßwerte wäre aber mal
> interessant ;)
NSLU2 interessiert mich nicht, da ich ja auch nicht mehr für den C64
entwickle :-)
Der Sheevaplug ist beim Komprimieren flott genug und das Auspacken auf
iPhone/Android-Händys ist schnell genug. Die Schwachstelle ist immer der
Datenverkehr. Ich ziele auf mobile Software und daher ist Kompression für
mich quasi 'Ehrensache' :-)
a.
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Andy Fuchs wrote:
> EDGE
~200 kBit/sec; richtig langsam ist das eigentlich nicht ...
>> (Ernstgemeinte Frage; xmllist o. ä., also FHEM-
>> interna, ruft doch niemand per GSM oder HCD auf; einzig für pgm2 wäre das
>> imho relevant -- und mit Apache-Wrapping auch zu erschlagen?)
>
> Bin ich anderer Meinung. Wozu baue ich mir ein remote-fähiges
> Heim-Automatisierungs-System und eine Software für's iPhone/Android, wenn
> ich es dann nur von zuhause benutze??? Das wäre blöd.
Hmm. Also den FHEM-Port weltweit zugänglich machen zu müssen (zumal, da
keinerlei Zugangschutz vorgesehen ist), würde mich von der App-Manie dann
doch schnell heilen. Schon wegen der Authentisierung braucht's da aus
meiner Sicht ein Stück Zusatzsoftware, welches dann auch gleich xmllist.gz
implementieren kann.
Wobei tendentiell das auch schon in FHEM reingehört, denn auch im lokalen
Netz, in dem sich z. B. latente Einfallstore wie DockStar (theoretisch kann
über eine vom DockStar ausgehende Verbindung auch auf den DockStar zuge-
griffen werden) oder demnächst die "smarten" Stromzähler tummeln, ist es
eher etwas unsicher, wenn man auf ein dokumentiertes Protokoll per telnet
einfach zu zugreifen kann. Port auf 7777 zu legen ist nur bedingt eine Lö-
sung ;) (Nächster Diskussionpunkt dann: welchen Sinn haben Passwörter im
LAN auf unverschlüsselten Verbindungen/Protokollen (-> tcpdump) ;))
> NSLU2 interessiert mich nicht, da ich ja auch nicht mehr für den C64
> entwickle :-)
Dann implementiere doch einfach xmllist.gz als Kommando und gut -- siehe
Wiki-Diskussion: machen, nicht reden ;)
> Der Sheevaplug ist beim Komprimieren flott genug und das Auspacken auf
> iPhone/Android-Händys ist schnell genug. Die Schwachstelle ist immer der
> Datenverkehr. Ich ziele auf mobile Software und daher ist Kompression für
> mich quasi 'Ehrensache' :-)
Wichtiger wäre mir ja Zugangssicherheit -- feste IP ist ja nicht und wäre
spätestens bei Roaming futsch --, aber nunja ;)
kai
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
On 07.01.10 12:15, "Kai 'wusel' Siering" wrote:
> Andy Fuchs wrote:
>
>> EDGE
>
> ~200 kBit/sec; richtig langsam ist das eigentlich nicht ...
Naja... aber man hat ja auch Traffic-Overhead und ausserdem nicht immer die
volle Geschwindigkeit. Darüberhinaus kommen die langsamen Connect-Zeiten, so
dass sich das halt zusammenläppert...
Ausserdem steht bei umfangreichen Listen nach meinen ersten Tests das
Verhältnis 1:14 im Raum. Will sagen: große Liste unkomprimiert 138.319 bytes
vs. komprimiert 9.802 bytes). Das lohnt sich also :-)
>
>>> (Ernstgemeinte Frage; xmllist o. ä., also FHEM-
>>> interna, ruft doch niemand per GSM oder HCD auf; einzig für pgm2 wäre das
>>> imho relevant -- und mit Apache-Wrapping auch zu erschlagen?)
>>
>> Bin ich anderer Meinung. Wozu baue ich mir ein remote-fähiges
>> Heim-Automatisierungs-System und eine Software für's iPhone/Android, wenn
>> ich es dann nur von zuhause benutze??? Das wäre blöd.
>
> Hmm. Also den FHEM-Port weltweit zugänglich machen zu müssen (zumal, da
> keinerlei Zugangschutz vorgesehen ist), würde mich von der App-Manie dann
> doch schnell heilen. Schon wegen der Authentisierung braucht's da aus
> meiner Sicht ein Stück Zusatzsoftware, welches dann auch gleich xmllist.gz
> implementieren kann.
Der muss ja nicht weltweit zugänglich sein, sondern z.B. über einen Proxy
seine Daten liefern. Und bei mir sitzt der Proxy nicht auf dem Sheevaplug...
> Dann implementiere doch einfach xmllist.gz als Kommando und gut -- siehe
> Wiki-Diskussion: machen, nicht reden ;)
Ich bevorzuge JSON, muss aber bei Gelegenheit erstmal rausfinden, wie ich
die JSONList so ausstatte, wie ich mir das vorstelle. Im Moment scheitert's
noch daran, dass ich Martin Fischer's jsonlib-code nicht gescheit lesen
kann... (mit oder ohne Brille :-))
>> Der Sheevaplug ist beim Komprimieren flott genug und das Auspacken auf
>> iPhone/Android-Händys ist schnell genug. Die Schwachstelle ist immer der
>> Datenverkehr. Ich ziele auf mobile Software und daher ist Kompression für
>> mich quasi 'Ehrensache' :-)
>
> Wichtiger wäre mir ja Zugangssicherheit -- feste IP ist ja nicht und wäre
> spätestens bei Roaming futsch --, aber nunja ;)
Glaub' mir - DAS wiederum ist das geringste Problem (zumindest von meiner
Seite) ;-)
a.
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Andy Fuchs wrote:
>> Hmm. Also den FHEM-Port weltweit zugänglich machen zu müssen (zumal, da
>> keinerlei Zugangschutz vorgesehen ist), würde mich von der App-Manie dann
>> doch schnell heilen. Schon wegen der Authentisierung braucht's da aus
>> meiner Sicht ein Stück Zusatzsoftware, welches dann auch gleich xmllist.gz
>> implementieren kann.
>
> Der muss ja nicht weltweit zugänglich sein, sondern z.B. über einen Proxy
> seine Daten liefern. Und bei mir sitzt der Proxy nicht auf dem Sheevaplug...
Und warum komprimiert der Proxy dann nicht einfach? Wenn "Proxy" nur ein
anderes Wort für Portforwarding ist, ist darüber der FHEM-Port auf dem
SheevaPlug doch weltweit zugänglich? Falls der "Proxy" Authentisierung
vornimmt (wie sonst willst Du verhindern, daß Dir jemand nach einem Port-
scan Deine FHEM-Konfiguration zermarmelt; klar, das dauert und klar, je-
den offenen Port durchzuprobieren ist auch zeitaufwendig und klar, wer kennt
schon FHEM, ...), kann er doch auch gleich generell für eine Kompression
der Kommunikation zwischen Applet und FHEM sorgen?
> Glaub' mir - DAS wiederum ist das geringste Problem (zumindest von meiner
> Seite) ;-)
Glauben tue ich in _dem_ Kontext nur das, was ich gesehen habe. Bislang
sehe ich da nix ;)
kai
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
On 07.01.10 12:54, "Kai 'wusel' Siering" wrote:
> Andy Fuchs wrote:
>
>>> Hmm. Also den FHEM-Port weltweit zugänglich machen zu müssen (zumal, da
>>> keinerlei Zugangschutz vorgesehen ist), würde mich von der App-Manie dann
>>> doch schnell heilen. Schon wegen der Authentisierung braucht's da aus
>>> meiner Sicht ein Stück Zusatzsoftware, welches dann auch gleich xmllist.gz
>>> implementieren kann.
>>
>> Der muss ja nicht weltweit zugänglich sein, sondern z.B. über einen Proxy
>> seine Daten liefern. Und bei mir sitzt der Proxy nicht auf dem Sheevaplug...
>
> Und warum komprimiert der Proxy dann nicht einfach?
Ich bin für 'saubere' Lösungen. Warum soll ich auf dem Proxy was
implementieren, was dort nicht hingehört?
> Wenn "Proxy" nur ein
> anderes Wort für Portforwarding ist,
Sollte es aber nicht sein. Im Übrigen gibt es natürlich -zig Varianten, wie
man das Ganze absichern kann. Aber darum geht's ja eigentlich auch nicht,
sondern mir ging's darum, dass die Kompression eben auf den Sender gehört
und nicht irgendwo zwischendrin - obwohl ich möglicherweise diesen Weg gehen
werde mangels Perl-know-how...
>
> Glauben tue ich in _dem_ Kontext nur das, was ich gesehen habe. Bislang
> sehe ich da nix ;)
Ich hab' na noch nicht mal eine jsonliste nach meinem Geschmack. Das dauert
also noch :-)
a.
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Andy Fuchs wrote:
>>> seine Daten liefern. Und bei mir sitzt der Proxy nicht auf dem Sheevaplug...
>> Und warum komprimiert der Proxy dann nicht einfach?
>
> Ich bin für 'saubere' Lösungen. Warum soll ich auf dem Proxy was
> implementieren, was dort nicht hingehört?
Wieso gehört das -- besondere Anforderungen für Spezialanwendungen -- nicht
in den Proxy? Im LAN brauchst Du keinen Proxy für Frontend X. Wenn dies auf
der gleichen Box läuft, braucht's nicht mal 'nen exponierten Zugang zum
Backend. Deine Anwendung hat ein Bandbreitenproblem (EDGE statt Ethernet),
zudem benötigt sie *zwingend* etwas, was a) den FHEM-Port im LAN aus den
Mobilfunknetzen (und damit, außer, Du dealst mit dem Provider, aus dem ge-
samten Internet) zugänglich macht und b) *hoffentlich* diesen ungeschützten
Zugang zumindest rudimentär absichert. Für mich gehört zur 'sauberen' Lösung
ein Proxy für diese Anwendung.
Solange Du das nur für Dich bastelst, bist Du ja frei, jede Schweinerei zu
machen (/me favorisiert da ja openvpn vom Androiden ins Heimnetz -- das kann
auch komprimieren ;)), aber als generische App ist der Zugriffsschutz doch
ein zentrales Thema? Und wenn man den realisiert, kann man auch gleich die
Datenmenge reduzieren ;)
Finde ich jetzt nicht unlogisch ... Aber: der Source ist zum Verändern da ;)
kai
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
On 7 Jan., 11:12, Andy Fuchs
wrote:
> On 07.01.10 10:46, "Kai 'wusel' Siering" wrote:
>
> > Andy Fuchs wrote:
> > (Ernstgemeinte Frage; xmllist o. ä., also FHEM-
> > interna, ruft doch niemand per GSM oder HCD auf; einzig für pgm2 wäre das
> > imho relevant -- und mit Apache-Wrapping auch zu erschlagen?)
>
> Bin ich anderer Meinung. Wozu baue ich mir ein remote-fähiges
> Heim-Automatisierungs-System und eine Software für's iPhone/Android, wenn
> ich es dann nur von zuhause benutze??? Das wäre blöd.
>
Meine Hausanlage steuere ich mit Android-Handy/pgm3 von ueberall
unterwegs ueber den Apache.
Schon eine coole Vorstellung, dass die ganze "Arbeit" direkt auf
Android/iPhone gemacht wird.
Ich haette natuerlich einfach eine Webseite geschrieben, die zur
Darstellung darauf optimiert waere. Apache ist ja wiederum optimiert,
um draussen im boesen WEB so mit Passwortschutz/Verschluesselung zu
arbeiten. Insofern muss da nichts zum FHEM komprimiert werden.
Aber, wie du mal geschrieben hast, Webseiten schreiben kann jeder ;-))
Martin
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
On 07.01.10 13:55, "Kai 'wusel' Siering" wrote:
> Andy Fuchs wrote:
>
>>>> seine Daten liefern. Und bei mir sitzt der Proxy nicht auf dem
>>>> Sheevaplug...
>>> Und warum komprimiert der Proxy dann nicht einfach?
>>
>> Ich bin für 'saubere' Lösungen. Warum soll ich auf dem Proxy was
>> implementieren, was dort nicht hingehört?
>
> Wieso gehört das -- besondere Anforderungen für Spezialanwendungen -- nicht
> in den Proxy? Im LAN brauchst Du keinen Proxy für Frontend X. Wenn dies auf
> der gleichen Box läuft, braucht's nicht mal 'nen exponierten Zugang zum
> Backend.
Also ich zippe sogar den internen Traffic bei mir im Heimnetz ;-)
> Deine Anwendung hat ein Bandbreitenproblem (EDGE statt Ethernet),
> zudem benötigt sie *zwingend* etwas, was a) den FHEM-Port im LAN aus den
> Mobilfunknetzen (und damit, außer, Du dealst mit dem Provider, aus dem ge-
> samten Internet) zugänglich macht und b) *hoffentlich* diesen ungeschützten
> Zugang zumindest rudimentär absichert. Für mich gehört zur 'sauberen' Lösung
> ein Proxy für diese Anwendung.
M o m e n t! :-)
Erstens braucht die Anwendung den offenen Port nicht *zwingend*.
Zweitens unterscheide ich zwischen Administration und Datenabfrage. Für
ersteres benötige ich direkten Zugriff - ich mache das über VPN. Der
Endanwender-Client geht sowieso über einen Proxy, da der ja in der Lage sein
soll, auf verschiedene Komponenten (also nicht nur fhem) zentral
zuzugreifen. Nichtsdestotrotz sollte die Kompressionsmöglichkeit dahin, wo
man am Besten von Ihr profitieren kann - und das ist nunmal m.E. nach das
Backend.
Rudi hatte ja schon einen netten Weg beschrieben, wie man das auch machen
kann - damit kann ich auch leben...
> Solange Du das nur für Dich bastelst, bist Du ja frei, jede Schweinerei zu
> machen (/me favorisiert da ja openvpn vom Androiden ins Heimnetz -- das kann
> auch komprimieren ;)),
siehe oben...
> aber als generische App ist der Zugriffsschutz doch
> ein zentrales Thema? Und wenn man den realisiert, kann man auch gleich die
> Datenmenge reduzieren ;)
> Finde ich jetzt nicht unlogisch ... Aber: der Source ist zum Verändern da ;)
Halb/halb... Mein Heimnetz liegt zu 95% hinter einem VPN (und dahinter
benötigt man z.T. nochmal ein separaten User/Pass für administrative
Zwecke). Die restlichen 5 sind (relativ) frei zugänglich, bzw. mit User/Pass
und z.T. https rudimentär gesichert.
Den Unterschied im Zugriffsschutz erledige ich also einerseits mit VPN,
andererseits mit der Client-Software - im Proxy wollte ich das nicht
unbedingt machen. Aber wenn man mich dazu zwingt, bleibt mir vielleicht nix
anderes übrig :-)
a.
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Andy Fuchs wrote:
>>> Ich bin für 'saubere' Lösungen. Warum soll ich auf dem Proxy was
>>> implementieren, was dort nicht hingehört?
>> Wieso gehört das -- besondere Anforderungen für Spezialanwendungen -- nicht
>> in den Proxy? Im LAN brauchst Du keinen Proxy für Frontend X. Wenn dies auf
>> der gleichen Box läuft, braucht's nicht mal 'nen exponierten Zugang zum
>> Backend.
>
> Also ich zippe sogar den internen Traffic bei mir im Heimnetz ;-)
Das würde bei meinen überwiegend MPEG2-Strömen (VDR/DVB-S) kaum Sinn
machen ;)
>> Deine Anwendung hat ein Bandbreitenproblem (EDGE statt Ethernet),
>> zudem benötigt sie *zwingend* etwas, was a) den FHEM-Port im LAN aus den
>> Mobilfunknetzen (und damit, außer, Du dealst mit dem Provider, aus dem ge-
>> samten Internet) zugänglich macht und b) *hoffentlich* diesen ungeschützten
>> Zugang zumindest rudimentär absichert. Für mich gehört zur 'sauberen' Lösung
>> ein Proxy für diese Anwendung.
>
> M o m e n t! :-)
>
> Erstens braucht die Anwendung den offenen Port nicht *zwingend*.
Verstehe ich nicht. *Ohne* Zugriff auf irgendwas von FHEM, und das einzige
mir bekannte Interface ist jenes über (normalerweise) Port 7072, was will
die Anwendung denn machen? Heuristisch raten, ob das Licht im Flur an oder
aus ist? ;)
> Zweitens unterscheide ich zwischen Administration und Datenabfrage. Für
> ersteres benötige ich direkten Zugriff - ich mache das über VPN. Der
> Endanwender-Client geht sowieso über einen Proxy, da der ja in der Lage sein
> soll, auf verschiedene Komponenten (also nicht nur fhem) zentral
> zuzugreifen.
QED. Damit ist es auch kein Proxy, sondern eine Anwendung im Heimnetz, die,
z. B. wie myHCE, verschiedene Dinge unter einer Oberfläche zusammenfaßt,
ein Teil davon ist eben FHEM. Nur daß $andere das über einen Webserver lösen
und Du Deine Software "Proxy" nennst. Für mich ist das 'ne Middleware, aber
gut, Streit um des Kaisers Bart ;) Jedenfalls braucht damit dann in der Tat
auch nicht die Anwendung auf Deinem Endgerät den Zugriff auf FHEM, sondern
Deine Zwischensoftware -- die die Daten dann für Dein Endgerät auch schön
komprimieren kann ;)
> Nichtsdestotrotz sollte die Kompressionsmöglichkeit dahin, wo
> man am Besten von Ihr profitieren kann - und das ist nunmal m.E. nach das
> Backend.
Sehe ich nach wie vor nicht. Im Hausautomationskontext spricht eine Haus-
automatisationsoberfläche mit anderen Hausnetz-, d. h. LAN-Komponenten;
Verschlüsselung würde ich als Anforderung sehen (ja, auch im LAN, IMHO,
bei _jenen_ Gerätschaften), Datenkompression oder -reduktion erst weit,
weit hinter fehlerfreier Funktion sowie Usability ;)
> Den Unterschied im Zugriffsschutz erledige ich also einerseits mit VPN,
> andererseits mit der Client-Software - im Proxy wollte ich das nicht
> unbedingt machen. Aber wenn man mich dazu zwingt, bleibt mir vielleicht nix
> anderes übrig :-)
Gezwungen wird hier doch keiner -- notfalls wird halt geforkt, gute alte
OSS-Tradition ;)
kai
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
On 07.01.10 17:06, "Kai 'wusel' Siering" wrote:
>> Also ich zippe sogar den internen Traffic bei mir im Heimnetz ;-)
>
> Das würde bei meinen überwiegend MPEG2-Strömen (VDR/DVB-S) kaum Sinn
> machen ;)
Zippen nicht aber nach H.264 transcoden und dann streamen... ;-)
>> M o m e n t! :-)
>>
>> Erstens braucht die Anwendung den offenen Port nicht *zwingend*.
>
> Verstehe ich nicht. *Ohne* Zugriff auf irgendwas von FHEM, und das einzige
> mir bekannte Interface ist jenes über (normalerweise) Port 7072, was will
> die Anwendung denn machen? Heuristisch raten, ob das Licht im Flur an oder
> aus ist? ;)
Das ist fast so zuverlässig, wie ohne Rückkanal ;-)
Oder wie Beckenbauer immer so schön sagt: 'Schaunmermal' :-)
> QED. Damit ist es auch kein Proxy, sondern eine Anwendung im Heimnetz, die,
> z. B. wie myHCE, verschiedene Dinge unter einer Oberfläche zusammenfaßt,
> ein Teil davon ist eben FHEM. Nur daß $andere das über einen Webserver lösen
> und Du Deine Software "Proxy" nennst. Für mich ist das 'ne Middleware, aber
> gut, Streit um des Kaisers Bart ;) Jedenfalls braucht damit dann in der Tat
> auch nicht die Anwendung auf Deinem Endgerät den Zugriff auf FHEM, sondern
> Deine Zwischensoftware -- die die Daten dann für Dein Endgerät auch schön
> komprimieren kann ;)
Schon gut... ich geb' auf ;-)
> Sehe ich nach wie vor nicht. Im Hausautomationskontext spricht eine Haus-
> automatisationsoberfläche mit anderen Hausnetz-, d. h. LAN-Komponenten;
Das kommt immer auf die Größe/Geschwindigkeit/Auslastung des Netzes an.
Meiner Erfahrung nach zahlt es sich immer aus, sich rechtzeitig um die
Performance zu kümmern.
> Gezwungen wird hier doch keiner -- notfalls wird halt geforkt, gute alte
> OSS-Tradition ;)
Zu kompliziert... Ich will mir ja nicht freiwillig noch mehr Baustellen
schaffen, als ich sowieso schon hab...
a.
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.