Alexander Gnauck wrote:
> Artur Hefczyc schrieb:
>>
>> On 4 Apr 2008, at 12:05, Richard Smith wrote:
>> Johannes Wagener wrote:
>>> Proposed XMPP Extension: IO DATA
>>
>>
>> I second this proposal.
>
> I also second this proposal.
>
> I have done lots of Jabber RPC stuff in the past. RPC is poor
Artur Hefczyc schrieb:
On 4 Apr 2008, at 12:05, Richard Smith wrote:
Johannes Wagener wrote:
Proposed XMPP Extension: IO DATA
I second this proposal.
I also second this proposal.
I have done lots of Jabber RPC stuff in the past. RPC is poorly
documented and supports only basic data types
On Sat, Apr 5, 2008 at 6:05 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
>
> Maybe we should change the title to "Web Services over XMPP"? :)
definetely
> However, I suppose that when most people think of web services they
> think of SOAP and the whole WS-* stack...
So let's teach them ho
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
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 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
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
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
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
Peter Saint-Andre schrieb:
Johannes Wagener wrote:
Proposed XMPP Extension: IO DATA
Hello,
here I submit a proposal for a new XEP called "IO DATA".
The XEP is already located in the XEP inbox directory:
URL: http://www.xmpp.org/extensions/inbox/io-data.html
However, the initial version is
Hi
Peter Saint-Andre schrieb:
Do you send it all through XMPP? Is it all in small chunks as in the
examples you wrote, ore there may be also bigger chunks of data? I'm
asking because I think that everybody here would like to know more
about real life examples of binary data transfer through XMPP
Johannes Wagener wrote:
> Proposed XMPP Extension: IO DATA
>
> Hello,
> here I submit a proposal for a new XEP called "IO DATA".
>
> The XEP is already located in the XEP inbox directory:
> URL: http://www.xmpp.org/extensions/inbox/io-data.html
>
> However, the initial version is erroneously mi
Fabio Forno wrote:
> (I crosspost this to the API mailing list, because I think that this
> problem is another use case of the more general problem of p2p
> communication between applications we are discussing; in the API ml we
> can brainstorm better)
>
> On Sun, Mar 30, 2008 at 8:38 PM, Egon W
On Sun, Mar 30, 2008 at 2:16 AM, Johannes Wagener
<[EMAIL PROTECTED]> wrote:
>
> Proposed XMPP Extension: IO DATA
>
> Hello,
> here I submit a proposal for a new XEP called "IO DATA".
>
> The XEP is already located in the XEP inbox directory:
> URL: http://www.xmpp.org/extensions/inbox/io-data
Dear Fabio, thank you for your comment/clarification about the term "REST".
Fabio Forno schrieb:
While it's true that in SOAP+XMPP specs there is no asynchronous
message exchange pattern (and that was a mistake, though I think it's
possible to add a new MEP), this is not related to REST. Neither
Fabio Forno schrieb:
BTW, let me say that asynchronous RPC support in XMPP is very
interesting for scientific workflow environments. This proposal
addresses two problems which are important limitations of current
approaches like SOAP over HTTP.
Indeed, it's interesting in general ;)
(I crosspost this to the API mailing list, because I think that this
problem is another use case of the more general problem of p2p
communication between applications we are discussing; in the API ml we
can brainstorm better)
On Sun, Mar 30, 2008 at 8:38 PM, Egon Willighagen
<[EMAIL PROTECTED]>
On Sun, Mar 30, 2008 at 7:09 PM, Fabio Forno <[EMAIL PROTECTED]> wrote:
> While it's true that in SOAP+XMPP specs there is no asynchronous
> message exchange pattern (and that was a mistake, though I think it's
> possible to add a new MEP), this is not related to REST. Neither the
> concept of
On Sun, Mar 30, 2008 at 2:16 AM, Johannes Wagener
<[EMAIL PROTECTED]> wrote:
> Proposed XMPP Extension: IO DATA
>
>
> Abstract: This specification defines an XMPP protocol extension for
> handling the input to and output from a remote entity.
>
Some remarks.
You write "While SOAP over XMPP suppo
24 matches
Mail list logo
