Chatstammtisch außerhalb des Forums?

Wenn ihr Vorschläge, Anderungswünsche oder was sonst auch immer habt, hier rein.

Moderator: wegus

Antworten

Welchen Chatclient bevorzugt Ihr?

IRC
4
27%
AIM
1
7%
Developer Collaboration
6
40%
Kein Interesse
1
7%
Egal welchen, alle okay
0
Keine Stimmen
Einen anderen Client
3
20%
 
Abstimmungen insgesamt: 15

Benutzeravatar
seapegasus
Beiträge: 594
Registriert: 29.06.2006, 18:32
Wohnort: Prag
Kontaktdaten:

Chatstammtisch außerhalb des Forums?

Beitrag von seapegasus » 02.03.2007, 14:26

Als Fortsetzung des anderen Threads über Chats -- wenn der Chat außerhalb des Forums wäre, d.h. in einem normalen Chatclient, welchen würde die Mehrheit bevorzugen?

AIM und IRC haben den Vorteil, dass sie auch aus Firmen heraus erreichbar sind (stimmt das für Euch?), und den Nachteil, dass sie halt nur Standardchateigenschaften bieten.

Developer Collaboration hat vorteilhafte Feature wie Syntaxeinfärbung und gibt echten Einblick in anderer Leute Projekte, aber share.java.net ist nicht zwangsweise von allen Firmenproxies aus erreichbar...

Benutzeravatar
recJake
Beiträge: 669
Registriert: 19.07.2006, 11:50
Wohnort: IDEs

Beitrag von recJake » 05.03.2007, 11:00

...aber share.java.net ist nicht zwangsweise von allen Firmenproxies aus erreichbar...
Korrekt!!! Und leider ist die Anbindung des CT nicht besonders gut, da es die Proxyeinstellungen der IDE vollkommen ignoriert. :(
J..e
Willst Du coden, so code. Willst Du nutzen, so nutze. Willst Du beides, lass es!

Benutzeravatar
seapegasus
Beiträge: 594
Registriert: 29.06.2006, 18:32
Wohnort: Prag
Kontaktdaten:

Beitrag von seapegasus » 05.03.2007, 11:07

Wenn man diesen Proxy-Bug reparieren wuerde, wuerde das Collaboration fuer dich einsetzbar machen? (Oder habt ihr noch zusaetzliche Einschraenkungen)

PS: Collaboration hat seine eigenen Proxyeinestellungen, hast Du die gesehen? werden die auch ignoriert?

Benutzeravatar
recJake
Beiträge: 669
Registriert: 19.07.2006, 11:50
Wohnort: IDEs

Beitrag von recJake » 05.03.2007, 11:30

Wenn man diesen Proxy-Bug reparieren wuerde, wuerde das Collaboration fuer dich einsetzbar machen? (Oder habt ihr noch zusaetzliche Einschraenkungen)
Nein, die einzige Einschränkung bei uns ist, daß man auf jeglichen Content im großen weiten Netz nur über einen Proxy zugreifen kann. Und das funktioniert bei allen möglichen Dingen wunderbar (z.B. Skype)
...Collaboration hat seine eigenen Proxyeinestellungen, hast Du die gesehen? werden die auch ignoriert?...
Genau das meine ich. Collab hat seine eigenen, obwohl die IDE schon welche hat. Der Fehler bei Collab ist, daß die von der IDE nicht ausreichen, sie müßten also nur erweitert, aber nicht ignoriert werden.
Es gibt ja nur folgende Einstellungen: "Direct Connection" <- geht nicht bei mir, weil ich ja nur über einen Proxy auf Webcontent zugreifen kann; "HTTPS" <- unterstützt unser Proxy nicht; "SOCKS5" <- unterstützt er auch nicht.
Was also fehlt, ist ein einfacher Proxy. :(
J..e
Willst Du coden, so code. Willst Du nutzen, so nutze. Willst Du beides, lass es!

Benutzeravatar
seapegasus
Beiträge: 594
Registriert: 29.06.2006, 18:32
Wohnort: Prag
Kontaktdaten:

Beitrag von seapegasus » 05.03.2007, 15:46

OK, ich hab mal fuer die Prioritaetisilitierung (? Bevorzugung?) dieser zwei Issue abgestimmt.

http://www.netbeans.org/issues/show_bug.cgi?id=60564

http://www.netbeans.org/issues/show_bug.cgi?id=64428

Oh warte, ich kann nur fuer eine der beiden abstimmen? Grmpf, auch recht.

Es scheint, die halten Proxy mit HTTP fuer zu unsicher, aber keine Ahnung, warum die Option deswegen komplett gestrichen wurde (koennte ja wenigstens mit einer Warnung versehen erlaubt werden).

Benutzeravatar
seapegasus
Beiträge: 594
Registriert: 29.06.2006, 18:32
Wohnort: Prag
Kontaktdaten:

Beitrag von seapegasus » 05.03.2007, 17:03

Also ich hab gerade Petr Nejedly gefragt, und der sagt, das das nicht trivial sei ohne HTTPS, weil in HTTPS die CONNECT-Methode die Arbeit uebernimmt. Ansonsten muessten man den Server-Dialog irgendwie umstaendlich hardcoden, um den selben Effekt zu erzielen.

Dann gaebe es zwar die moeglichkeit, XMPP http polling zu benuzten, das kann zwar die collab library, aber weder der client noch der server. (Oder so.)

Er wiederholte, dass die einzige Moeglichkeit sei, dass Euer Admin eine exemption rule schreibt. Es ist schliesslich ein Arbeitstool und kein Blalaberfasel-Chat, wo Hinz und Kunz rumhaengen, glaubst Du, Du kaemest damit durch?

Oder ansonsten, wenn Du abends Zeit privat zuhause haettest?

Benutzeravatar
recJake
Beiträge: 669
Registriert: 19.07.2006, 11:50
Wohnort: IDEs

Beitrag von recJake » 06.03.2007, 12:39

... glaubst Du, Du kaemest damit durch?...
Eher nicht! Erklärung weiter unten.
... Oder ansonsten, wenn Du abends Zeit privat zuhause haettest...
Never ever. Ich werde mir zu Hause keinen I-Net Anschluß installieren lassen. ;)

So, hab das Problem mal eingegrenzt. Unser Firmenproxy kommuniziert nur über den Http-Port (also 80) mit der Außenwelt. Eine HTTPS-Kommunikation (hab nochmal nachgefragt-unser proxy kann doch https) auf diesem Port lehnt der Server von share.java.net aber ab:
Response from server: HTTP/1.1 502 Proxy Error ( The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port. Most Web browsers use port 443 for SSL requests. )
Daß der Server nur 443 akzeptiert ist schon etwas kritisch, aber durchaus verständlich :(
Bei uns wird aber auf keinen Fall ein anderer Port geöffnet. So sind die Sicherheitsrichtlinien. :(
J..e
Willst Du coden, so code. Willst Du nutzen, so nutze. Willst Du beides, lass es!

Benutzeravatar
seapegasus
Beiträge: 594
Registriert: 29.06.2006, 18:32
Wohnort: Prag
Kontaktdaten:

Beitrag von seapegasus » 06.03.2007, 13:02

recJake hat geschrieben:HTTPS-Kommunikation (hab nochmal nachgefragt-unser proxy kann doch https) auf diesem Port lehnt der Server von share.java.net aber ab:
Response from server: HTTP/1.1 502 Proxy Error ( The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port. Most Web browsers use port 443 for SSL requests. )
Daß der Server nur 443 akzeptiert ist schon etwas kritisch, aber durchaus verständlich :(
Bei uns wird aber auf keinen Fall ein anderer Port geöffnet. So sind die Sicherheitsrichtlinien. :(
Also wenn ich das richtig verstehe, benutzt Euer Server ausschliesslich den Defaultport fuer HTTPS, aber das Problem ist, dass share.java.net einen anderen erwartet, und Du das nicht auf was anderes als 443 umschalten kannst?

Also ist die neue Frage an das collab-Team, ob sie auch alternativ 443 erlauben koennen?

Benutzeravatar
recJake
Beiträge: 669
Registriert: 19.07.2006, 11:50
Wohnort: IDEs

Beitrag von recJake » 06.03.2007, 14:17

Also wenn ich das richtig verstehe, benutzt Euer Server ausschliesslich den Defaultport fuer HTTPS, aber das Problem ist, dass share.java.net einen anderen erwartet, und Du das nicht auf was anderes als 443 umschalten kannst?

Also ist die neue Frage an das collab-Team, ob sie auch alternativ 443 erlauben koennen?
Nein, unser Proxy erlaubt Kommunikation nur über Port 80, egal ob rein oder raus und egal welches Protokoll (HTTP oder FTP oder gopher oder eben HTTPS).
Wenn ich also 443 einstelle kann ich noch nichtmal irgendeine Verbindung aufbauen.
Der Default-SSL-Port (also 443) ist bei uns gesperrt. Es nützt also garnichts, wenn das Collab-Team den Port 443 erlaubt, ich kann ihn ja eh nicht benutzen. :(

Naja ist auch egal, so wichtig ist es ja nun auch wieder nicht :)
J..e
Willst Du coden, so code. Willst Du nutzen, so nutze. Willst Du beides, lass es!

Benutzeravatar
seapegasus
Beiträge: 594
Registriert: 29.06.2006, 18:32
Wohnort: Prag
Kontaktdaten:

Beitrag von seapegasus » 06.03.2007, 17:33

OK, ist echt nicht trivial, wollte nur sichergehen, dass es keine einfache Loesung gibt, die wir uebersehen...

Wir koennen auch zwei Chats haben, in zwei verschiedenen Systemen, und dann sehen, wie weit wir kommen, und welches beliebter ist.

Benutzeravatar
wegus
Beiträge: 458
Registriert: 26.09.2006, 09:07

Beitrag von wegus » 06.12.2007, 12:31

nur so als Anregung:

wie wäre es mit einer in das Forum integrierten Shoutbox statt chat!?

Vorteil: sie läuft schnöde über Port 80, Anmeldung(Zugriff) kann via Forenanmeldung ggf. gekoppelt werden.

Nachteil: HTTP-bedingt muß aktiv nach neuen Shouts geguckt werden (reload). Durch AJAX läßt sich sowas aber ggf. reduziern/verhindern.
Wenn etwas zu einfach klingt um wahr zu sein, dann ist es oft auch nicht wahr!

Benutzeravatar
smurfi
Site Admin
Beiträge: 1641
Registriert: 29.06.2006, 11:33
Wohnort: Wuppertal
Kontaktdaten:

Beitrag von smurfi » 06.12.2007, 12:54

Hallo,

wenn so etwas gewünscht ist kann ich mich gerne mal danach umsehen ...

Gruss
Michael

Antworten