On Sun, Mar 30, 2008 at 8:13 PM, Justin Karneges
<[EMAIL PROTECTED]> wrote:
> On Sunday 30 March 2008 7:34 pm, anders conbere wrote:
> > However in XMPP our roster grouping are still relegated to binning or
> > boxing (an item in a group exists in one and only one group).
>
> Actually, in XMPP a
On Sunday 30 March 2008 7:34 pm, anders conbere wrote:
> However in XMPP our roster grouping are still relegated to binning or
> boxing (an item in a group exists in one and only one group).
Actually, in XMPP a contact may be in multiple groups. In fact, the grouping
is more like "tagging" than
I think that we've seen some fairly convincing examples of how
labeling or tagging can reduce the complexity of grouping sets of
data, in particular when it might be difficult to assign the data
items into only on individual group. Some big uses of tagging as the
primary form of grouping includes g
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
Fabio Forno wrote:
> On Sat, Mar 29, 2008 at 8:59 PM, Pedro Melo <[EMAIL PROTECTED]> wrote:
>> I have nothing very strong against Data Forms. My point was that, for
>> clients that use XPath to parse the known parts of the stanza (and
>> transparently ignore anything that the client does not sup
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 Sat, Mar 29, 2008 at 8:59 PM, Pedro Melo <[EMAIL PROTECTED]> wrote:
>
> I have nothing very strong against Data Forms. My point was that, for
> clients that use XPath to parse the known parts of the stanza (and
> transparently ignore anything that the client does not support), data
> forms a
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
Tomasz,
Quoting Tomasz Sterna <[EMAIL PROTECTED]>:
There's one other idea I have, but it may break backward
compatibility
and I'm not sure if it doesn't break something else: what if JIDs
like
'domain.com' are treated like 'wildcards' (like it is now), but
'@domain.com' are considered to be ex
Dnia 2008-03-30, nie o godzinie 13:20 +0300, Alexander Tsvyashchenko
pisze:
> There's one other idea I have, but it may break backward
> compatibility
> and I'm not sure if it doesn't break something else: what if JIDs
> like
> 'domain.com' are treated like 'wildcards' (like it is now), but
>
Peter,
Quoting Peter Saint-Andre <[EMAIL PROTECTED]>:
Well, in fact I think I've found already one case when this is a
problem, not only for collections listing, but also for their removal
and for preferences storing, see my message:
http://mail.jabber.org/pipermail/standards/2007-November/01
16 matches
Mail list logo
