Richard Smith wrote:
> Johannes Wagener wrote:
>> Proposed XMPP Extension: IO DATA
>
>
> +1
>
> I'd like to endorse this proposal.
>
> While AD-Hoc commands and Data Forms does offer a lot of flexibility, XMPP
> could benefit from extended capability in terms of representation of in
> terms of
Johannes Wagener wrote:
> Peter Saint-Andre schrieb:
>
>> Yes, ad-hoc commands can include payloads other than XEP-0004 data
>> forms. It's good to see someone using that extensibility.
>>
>> Just curious: did you look at XForms?
>>
> I looked at XForms. XForms is primarily used for a form based
Ola Spjuth wrote:
> Hi,
>
> I'd like to add our strong support to the "IO DATA" XEP proposal. I
> represent the Bioclipse project (www.bioclipse.net) providing a
> workbench for life science that currently relies heavily on SOAP Web
> services for remote execution of jobs. The biggest problem for
This applies to MUC, privacy lists, and message archiving, so I'm
changing the subject...
Alexander Tsvyashchenko wrote:
>
> Peter,
>
> Quoting Peter Saint-Andre <[EMAIL PROTECTED]>:
>
I think it is counter-intuitive.
Logic would hint that domain.com is exact match and @domain.com is
Hi Boyd, thanks for posting about this.
Boyd Fletcher wrote:
> Over the last couple of years we have discussed various approaches to add
> digital signature support to XMPP
In fact we haven't had many discussions about digital signatures, mostly
about end-to-end encryption. :)
> that did not vi
Luis Peralta wrote:
>Overall I like this XEP. What I missed are more possible status
> values for the commands. Being in execution and completed is way too
> simple for some applications. The initial state after submitting a
> command would be 'accepted' and letting the client know that it
On Fri, Apr 4, 2008 at 5:35 PM, Luis Peralta <[EMAIL PROTECTED]> wrote:
>
>Overall I like this XEP. What I missed are more possible status
> values for the commands. Being in execution and completed is way too
> simple for some applications. The initial state after submitting a
> command
On Sun, Mar 30, 2008 at 10:59 PM, Johannes Wagener
<[EMAIL PROTECTED]> wrote:
> Indeed. If you read the xep you might see that the XEP is very much the
> same as you suggest here. Ad-Hoc Commands do also support several
> actions: For example execute/next/prev/cancel/complete are actions
> sup
On 4 Apr 2008, at 12:05, Richard Smith wrote:
Johannes Wagener wrote:
Proposed XMPP Extension: IO DATA
I second this proposal.
I've read this XEP and I love it.
This is exactly what I needed when I was working on the server
configuration
via XMPP. I decided to use ad-hoc commands becaus
On Fri Apr 4 15:55:26 2008, Philipp Hancke wrote:
Dave Cridland wrote:
[...]
Sure, I think everyone here does. I sincerely hope so, anyway - we
will have significant impact here in the future.
We agree that messages should be sent only once per link?
Ideally, yes. In fact, ideally, less th
On Sun, 2008-03-30 at 01:16 +0100, Johannes Wagener wrote:
> Further explanation comes here:
> We want to do dynamic Web Services over XMPP. For certain reasons we
> explain in the XEP we think neither SOAP over XMPP nor Jabber-RPC is
> the way to go. We think future asynchronous Web Services can
On Fri, Apr 4, 2008 at 8:58 PM, Philipp Hancke <[EMAIL PROTECTED]>
wrote:
> Tobias Markmann wrote:
>
> At least initial presence is distributed...and that's not nothing :)
> > However
> >
>
> No. The initial presence s distributed using the old repeater. See
> http://hancke.name/jabber/repeater-u
Tobias Markmann wrote:
At least initial presence is distributed...and that's not nothing :) However
No. The initial presence s distributed using the old repeater. See
http://hancke.name/jabber/repeater-usage.html#muc-enter for details.
p
Carlo v. Loesch typeth:
| So after being mislead by XEP-0033 this time around they have a new
| chance of taking a wiser decision. Of course there are things that
A language problem with the word 'mislead' was pointed out to me.
Apparently it implies that a person intentionally did something
evil.
2008/3/30, Johannes Wagener <[EMAIL PROTECTED]>:
> Proposed XMPP Extension: IO DATA
>
> Hello,
> here I submit a proposal for a new XEP called "IO DATA".
>
Hi,
Overall I like this XEP. What I missed are more possible status
values for the commands. Being in execution and completed is way to
>
> On Fri, Apr 4, 2008 at 4:55 PM, Philipp Hancke <[EMAIL PROTECTED]>
> wrote:
>
There are situations where there is no gain:
>
* user joins
>
* muc service modifies repeater
>
* users leaves
>
* muc service modifies repeater
>
two repeater modifications for nothing
At least initial presence is
Dave Cridland wrote:
[...]
Sure, I think everyone here does. I sincerely hope so, anyway - we will
have significant impact here in the future.
We agree that messages should be sent only once per link?
[...]
You do, however, raise a very interesting point - you've said that in
the current MUC
On Fri, Apr 4, 2008 at 4:03 PM, Carlo v. Loesch <[EMAIL PROTECTED]>
wrote:
> Carlo v. Loesch typeth:
> | more gain in MUC and pubsub, but you can't say that 50% protocol
>
> Maths wins over memory: 60% of 70% is 42%, not 50%.
>
> Since pubsub and MUC are hardly relevant, XMPP has a problem
> with
Carlo v. Loesch typeth:
| more gain in MUC and pubsub, but you can't say that 50% protocol
Maths wins over memory: 60% of 70% is 42%, not 50%.
Since pubsub and MUC are hardly relevant, XMPP has a problem
with 42% of all XMPP stanzas on the network being redundant overhead.
That's why I repeatedl
| > A quick data-point: the largest pubsub node *right now*, has a bit
| > over 73000 (73056 to be exact) subscribers, the top 3 are all above
| > 72k. And this service is only for local users of the server.
Dave Cridland typeth:
| To state the obvious (which I'm sure you know), nothing's go
Dave Cridland typeth:
| again, it gives directed acyclic routing to MUC, which repeaters
| don't do. (Well, I hope not).
My Multicast Repeaters suggestion does just that, but without
the overhead of having MUC apps running on every node.
Why do you hope Repeaters do not solve your problem?
Two
Hi,
I'd like to add our strong support to the "IO DATA" XEP proposal. I
represent the Bioclipse project (www.bioclipse.net) providing a
workbench for life science that currently relies heavily on SOAP Web
services for remote execution of jobs. The biggest problem for us is
long lasting ca
On Fri Apr 4 11:28:50 2008, Pedro Melo wrote:
Yes, that was not the point of this, it was only to show that this
problem is important now, and not "when we have 100k subscribers in
the future". The future is here now.
Ah, but it isn't. :-)
I mean, the future's never here now, of course
On Apr 4, 2008, at 11:57 AM, Alexander Gnauck wrote:
Pedro Melo schrieb:
Yes, that was not the point of this, it was only to show that this
problem is important now, and not "when we have 100k subscribers
in the future". The future is here now.
Thank Pedro for pointing this out. I was look
Johannes Wagener wrote:
> Proposed XMPP Extension: IO DATA
+1
I'd like to endorse this proposal.
While AD-Hoc commands and Data Forms does offer a lot of flexibility, XMPP
could benefit from extended capability in terms of representation of in
terms of machine-to-machine communications that are
Pedro Melo schrieb:
Yes, that was not the point of this, it was only to show that this
problem is important now, and not "when we have 100k subscribers in the
future". The future is here now.
Thank Pedro for pointing this out. I was looking at the pubsub nodes on
jabber.org which is one of th
Hi,
On Apr 4, 2008, at 10:35 AM, Dave Cridland wrote:
On Fri Apr 4 09:16:34 2008, Pedro Melo wrote:
On Apr 3, 2008, at 10:40 PM, Alexander Gnauck wrote:
Carlo v. Loesch schrieb:
Yes, that's why I started thinking about something better in 1990.
I understood there was no way for IRC to be 'fi
On Fri Apr 4 09:16:34 2008, Pedro Melo wrote:
On Apr 3, 2008, at 10:40 PM, Alexander Gnauck wrote:
Carlo v. Loesch schrieb:
Yes, that's why I started thinking about something better in 1990.
I understood there was no way for IRC to be 'fixed' because its
design
is fundamentally flawed. XMP
On Thu Apr 3 22:40:48 2008, Alexander Gnauck wrote:
Carlo v. Loesch schrieb:
Yes, that's why I started thinking about something better in 1990.
I understood there was no way for IRC to be 'fixed' because its
design
is fundamentally flawed. XMPP is only syntactically flawed, which
is
a much
On Apr 3, 2008, at 10:40 PM, Alexander Gnauck wrote:
Carlo v. Loesch schrieb:
Yes, that's why I started thinking about something better in 1990.
I understood there was no way for IRC to be 'fixed' because its
design
is fundamentally flawed. XMPP is only syntactically flawed, which is
a much
30 matches
Mail list logo
