i think we also should setup a participant list on the Wiki. So all
members/developers who are interested to participate the event can
signup there.
I think most of us have to stay in a hotel for some days, so we should
recommend 1 or 2 hotels.
Alex
Peter Saint-Andre wrote:
The devcon /
It's a wiki -- feel free to edit. :-) I've started an attendee list at
the relevant page:
http://wiki.jabber.org/index.php/Interop_Event
Alexander Gnauck wrote:
i think we also should setup a participant list on the Wiki. So all
members/developers who are interested to participate the event
On 2006-12-24, Matt Mankins wrote:
Hi All.
Hey Matt, it's good to see your name on the mailing lists again. :-)
I recently created some code which implements XEP 124, HTTP Binding via
Danga's Perlbal reverse proxy server into subversion today:
svn://code.loremlabs.com/xmpp-binder/
Hey Matthias, that's great news. But don't you think that it's a bit odd
to have jabberd14 1.6? :-) Maybe jabberd1 is better...
Matthias Wimmer wrote:
Hi!
I am very happy to be finally able to announce the availability of
version 1.6.0 of jabberd14.
http://download.jabberd.org/jabberd14/
Peter Saint-Andre schreef:
Hey Matthias, that's great news. But don't you think that it's a bit odd
to have jabberd14 1.6? :-) Maybe jabberd1 is better...
jabberd1 looks a bit like jabberdl; maybe another point of confusion :D
--
Mvg, Sander Devrieze.
So many times people have brought this up, but at no time has anyone
written up a spec for it. I wonder why?
Do you want to include *all* XHTML content? Scripts? Media objects? Forms?
If so, feel free to write up a spec for that. To me, it seems like a bad
idea.
Peter
JD Conley wrote:
We
i think we had this discussion several times before. jabberd1 or jabberd
1.x tends always to confusion because all newbies to which i talked in
jdev see jabberd2 as the successor of jabberd1 which is wrong.
Sander Devrieze wrote:
Peter Saint-Andre schreef:
Hey Matthias, that's great news. But
i agree that it's a bad idea for chat messages.
But i talked to many people who want to send type='normal' in HTML like
email. And in email there is also no restriction of allowed tags.
I personally don't care much about XHTML and still try to send 99% of my
email in plain text only.
I agree
Alexander Gnauck wrote:
i agree that it's a bad idea for chat messages.
But i talked to many people who want to send type='normal' in HTML like
email. And in email there is also no restriction of allowed tags.
Oh well sure. But that's a different use case. :-)
I personally don't care much
Peter Saint-Andre wrote:
Alexander Gnauck wrote:
I would like prefer smth which allows multipart
messages with different content types where plain text is always
required. Content types could be plain text, xhtml, rtf etc...
Hmm, there are many issues with email to jabber translation
Maciek Niedzielski wrote:
Peter Saint-Andre wrote:
Alexander Gnauck wrote:
I would like prefer smth which allows multipart
messages with different content types where plain text is always
required. Content types could be plain text, xhtml, rtf etc...
Hmm, there are many issues with email to
Peter Saint-Andre wrote:
Maciek Niedzielski wrote:
Peter Saint-Andre wrote:
Alexander Gnauck wrote:
I would like prefer smth which allows multipart
messages with different content types where plain text is always
required. Content types could be plain text, xhtml, rtf etc...
Hmm, there are
ya this looks nice.
AS also Peter mentioned the problem will be the binary inline content if
it's getting to big. Then receiving this message blocks your whole XMPP
connection. For small inline content (small images) this will work fine.
A workaround for this problem is to send the main
Maciek Niedzielski wrote:
Peter Saint-Andre wrote:
Maciek Niedzielski wrote:
Peter Saint-Andre wrote:
Alexander Gnauck wrote:
I would like prefer smth which allows multipart
messages with different content types where plain text is always
required. Content types could be plain text, xhtml,
Alexander Gnauck schreef:
i think we had this discussion several times before. jabberd1 or jabberd
1.x tends always to confusion because all newbies to which i talked in
jdev see jabberd2 as the successor of jabberd1 which is wrong.
What about making the release numbers of jabberd14 negative
What about just making whitespace significant in the xmpp spec?
i.e. most client will want to replace space with nbsp before
displaying to the user, or maybe you can set a flag on the html
renderer
On 12/15/06, Bernhard Zwischenbrugger [EMAIL PROTECTED] wrote:
Depends on encoding
nbsp; is
Hi Sander!
Sander Devrieze schrieb:
What about making the release numbers of jabberd14 negative to solve the
problem? :o)
Hey ... this is a really cool idea! I like it very much. :-))
Matthias
--
Matthias Wimmer Fon +49-700 77 00 77 70
Züricher Str. 243Fax +49-89 95 89 91 56
81476
Whitespace is significant in the body/ element, no?
Norman Rasmussen wrote:
What about just making whitespace significant in the xmpp spec?
i.e. most client will want to replace space with nbsp before
displaying to the user, or maybe you can set a flag on the html
renderer
On 12/15/06,
True, so we need to remind client developers that it's significant in
the html node too, and that it's the job of the _receiving_ client to
ensure that the whitespace is preserved (not the sending client)
By making it a receiving job, we keep the bandwidth down :-)
On 1/4/07, Peter Saint-Andre
Norman Rasmussen wrote:
Whitespace is significant in the body/ element, no?
True, so we need to remind client developers that it's significant in
the html node too, and that it's the job of the _receiving_ client to
ensure that the whitespace is preserved (not the sending client)
Just a
Matthias Wimmer wrote:
Hi Sander!
Sander Devrieze schrieb:
What about making the release numbers of jabberd14 negative to solve
the problem? :o)
Hey ... this is a really cool idea! I like it very much. :-))
Well, now that I look more closely, it's jabberd14 -- I guess that's
the codebase
On Thursday 04 January 2007 12:07 pm, Alexander Gnauck wrote:
ya this looks nice.
AS also Peter mentioned the problem will be the binary inline content if
it's getting to big. Then receiving this message blocks your whole XMPP
connection. For small inline content (small images) this will work
gosh I hope not.
On 1/4/07, Maciek Niedzielski [EMAIL PROTECTED] wrote:
Norman Rasmussen wrote:
Whitespace is significant in the body/ element, no?
True, so we need to remind client developers that it's significant in
the html node too, and that it's the job of the _receiving_ client to
On Thursday 04 January 2007 1:04 pm, Maciek Niedzielski wrote:
Norman Rasmussen wrote:
Whitespace is significant in the body/ element, no?
True, so we need to remind client developers that it's significant in
the html node too, and that it's the job of the _receiving_ client to
ensure
Justin Karneges wrote:
This begs the question: what is too big? Currently, we consider stanza size
to be somewhat unbounded, as XMPP-Core imposes no size maximum. But I
believe we do need some mechanism for a stanza maximum size, otherwise XMPP
software is prone to denial-of-service attacks.
Justin Karneges wrote:
This begs the question: what is too big? Currently, we consider
stanza size
to be somewhat unbounded, as XMPP-Core imposes no size maximum. But
I
believe we do need some mechanism for a stanza maximum size,
otherwise XMPP
software is prone to denial-of-service
Justin Karneges wrote:
On Thursday 04 January 2007 1:04 pm, Maciek Niedzielski wrote:
Norman Rasmussen wrote:
Whitespace is significant in the body/ element, no?
True, so we need to remind client developers that it's significant in
the html node too, and that it's the job of the _receiving_
Hi
The nbsp; depends on character encoding only, it hasn't much to do
with xmpp.
It's the same with
uuml; for ü
ouml; for ö
...
If you want to use nbsp; you have to start the stream with
us-ascii (which is default encoding for html - xhtml has utf-8 as
default encoding):
?xml version='1.0'
On Fri, Jan 05, 2007 at 12:35:05AM +0100, Bernhard Zwischenbrugger wrote:
Hi
The nbsp; depends on character encoding only, it hasn't much to do
with xmpp.
In fact it does:
http://www.xmpp.org/rfcs/rfc3920.html#xml-restrictions
So the only predefined entities allowed are:
!ENTITY lt
Hi,
I wrote a simple script that can be used for xmpp-pinging.
http://machekku.uaznia.net/jabber/xmppping/xmppping-0.1.tar.gz
(requires python and PyXMPP)
It tries to mimic ping command, so should be not so hard to use ;)
To have some practical use cases, it returns 0 if there was at least one
30 matches
Mail list logo
