Re: [Standards] XEP-136 and XEP-59 implementation comments
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/017205.html ... skipped ... Of course I do not claim to be representative user here: I use ICQ and, especially, MSN gateways not that much recently, but error messages from gateways (wich comprise all of the direct messages from these domain JIDs) are coming regardless whether I use these gateways or not. Why are you logging error messages? :) Yes, exactly!!! ;-) Yes but I think this issue applies more broadly (e.g., to MUC and privacy lists also). So we need to think up a more general solution. Do you think the approach with adding in all these cases attribute like exact or exactMatch (so that JID is treated literally instead of like mask) is too hacky? 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 exact matches of domain JID (so, basically, JID with empty user name)? The same for resources: '[EMAIL PROTECTED]' is treated like wildcard, but '[EMAIL PROTECTED]/' is exact match of bare JID? Good luck! Alexander This message was sent using IMP, the Internet Messaging Program.
Re: [Standards] XEP-136 and XEP-59 implementation comments
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 exact matches of domain JID (so, basically, JID with empty user name)? The same for resources: '[EMAIL PROTECTED]' is treated like wildcard, but '[EMAIL PROTECTED]/' is exact match of bare JID? I think it is counter-intuitive. Logic would hint that domain.com is exact match and @domain.com is a wild match. Similar with [EMAIL PROTECTED] is exact match and [EMAIL PROTECTED]/ is wild match. Yes, probably, but that would break current behavior for sure, while the original approach seems to be less dangerous in this respect ... If backward compatibility is not a problem, though, I personally would be happy with either way of doing it. (Yet on the other hand, though, intuition is quite subjective thing; I can certainly see your point, but the other view might be if user part is not specified at all - this means we want all users, but if '@' is specified - this means sender took the effort to include the user part, and user name being empty means sender wants precisely this: i.e. domain JID) Good luck! Alexander This message was sent using IMP, the Internet Messaging Program.
Re: [Standards] Proposed XMPP Extension: IO DATA
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 supports complex functionality it lacks an obvious mechanism for asynchronous usage (for example it has no default RESTful design: there is no sessionid like in Ad-Hoc Commands). 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 session id is somewhat related to REST, at the contrary, REST explicitly forbids things like session ids. The basic principles of REST in fact are: - being able to address resources with URIs; since ad hoc commands end points nodes, whose URI may be xmpp:[EMAIL PROTECTED]/resource;node=nodename (if I remember well), they are RESTful in this aspect - be able to do actions (verbs like post/get/delete/put) on that resources; in this ad hoc commands are not RESTful, since they don't define a real action, they just provide a generic execute - stateless operations, and state or sessions are intentionally left out from REST, since they are too much application dependent; ad hoc commands have just a limited session concept, which is a sequence of operations forming a wizard with a start and an end. However applications may have different concepts of sessions, such as all operation between a login and logout, on a given resource or on a set of resources, or all operations in period of time; these are all concepts more complex than the model provided by ad hoc commands. For this reason I'd leave the responsibility of handling a session to the application, which should find a way for passing state information among requests as cookies or other mechanisms in HTTP. bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] Proposed XMPP Extension: IO DATA
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 session id is somewhat related to REST, at the contrary, REST explicitly forbids things like session ids. Fabio, thank you for catching this misqualification. We'll fix this shortly. 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. 1. many different data types. This is particularly a problem in (bio-)chemical sciences, where experimental data is found in many, many data types, which, moreover, are increasingly semantic. Currently, SOAP often cannot validate input unless the call has been made, while this proposal promises to allow to do this at the gate. Big improvement. 2. asynchronise calls. This is also a big limitation of our current tools. Call-by-reference does solve the problem of HTTP time outs on intermediate IP packet routers, but the only way to do long running jobs is to have the client use a second 'service' to poll the primary service and ask if it is done yet. XMPP is provides a much nicer protocol for such situations, and this proposal formalizes this. These two items combined, make this proposal an excellent candidate for running webservices in sciences like chemistry and biology. I am not too much into XMPP myself, but hope the discussions on this mailing list will help us get the proposal in shape, because we really like to see this functionality. The example code from Johannes looks great, and eager to start using it. We are setting up webservices for metabolomics, where the data that needs to be passed around goes in the gigabytes, and where processing easily goes into the tens of minutes. I am aware that we continue the unofficial extension of Edrin, but having this as an official XEP will make it much easier to roll out XMPP-based webservices on a larger scale. Looking forward to hearing further comments! Egon -- Post-doc in Metabolomics Wageningen Universtity Research Center, The Netherlands http://chem-bla-ics.blogspot.com/
Re: [Standards] Proposed XMPP Extension: IO DATA
(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] wrote: 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 ;) 1. many different data types. This is particularly a problem in [...] 2. asynchronise calls. This is also a big limitation of our current tools. Call-by-reference does solve the problem of HTTP time outs on [...] These two items combined, make this proposal an excellent candidate for running webservices in sciences like chemistry and biology. I understand the scenario, as I've written it's more general than scientific or biological computations (e.g send the input events from a UI widget placed somewhere to a remote service). Basically you'd like to do something like this: - retrieve a data scheme from an end point - send data to that end point - receive (also asynchronously) data from that end point Let's try to RESTify it in order to have a more general solution: - retrieving the data scheme is an operation on a particular node (a GET), so we don't need a particular action, just get it from the correct node, e.g. GET /nodename/schemata iq from=... to=... id=... type=set rest node=/nodename/schemata action=get xmlns=api:rest/ /iq - sending data is another operation on the node (the semantics of the operation on the data is given by the combination of the data and the node): POST /nodename payload iq from=... to=... id=... type=set rest node=/nodename action=post xmlns=api:rest header!-- optional --/header body!-- optional xml payload--/body rest/ /iq - receiving the result depends on whether the operation is synchronous or not. If synchronous it's just the payload of the answer, and we can correlate them using the id in the iq/ stanza. If asynchronous the service should create a session on the client, by adding the session id to the headers of the subsequent asynchronous messages (this mechanism is application defined, other applications may create a specialized node or use other strategies for handling sessions) iq from=... to=... id=... type=result rest xmlns=api:rest header session id= xmlns=api:sessionopen//session /header rest/ /iq Well, this is just a first attempt to brainstorm... The structure is much like HTTP, where we have actions, headers (for carrying optional metadata concerning the document) and the exchanged document, with all the semantics left to the application. In this way we have the same expressiveness of HTTP, with the advantage of a bidirectional asynchronous support as XMPP. I am not too much into XMPP myself, but hope the discussions on this mailing list will help us get the proposal in shape, because we really like to see this functionality. The example code from Johannes looks great, and eager to start using it. We are setting up webservices for metabolomics, where the data that needs to be passed around goes in the gigabytes, and where processing easily goes into the tens of minutes. 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. Keep us informed about the performance and the setup you use. I am aware that we continue the unofficial extension of Edrin, but having this as an official XEP will make it much easier to roll out XMPP-based webservices on a larger scale. Looking forward to hearing further comments! sure bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] Proposed XMPP Extension: IO DATA
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 think so, too. Therefore as our protocol is a very general approach we sent the specs to the standards mailing list. It's worth to note that we already wrote an opensource client and component side library for this protocol to be used from java or scripting languages to discover/invoke/manage (start/cancel/continue/complete) remote processes. The sample code in the section 1.3 of the XEP proposal is very similar to how it is actually implemented. We hope that other libraries will have interest in the protocol in future, too. 1. many different data types. This is particularly a problem in [...] 2. asynchronise calls. This is also a big limitation of our current tools. Call-by-reference does solve the problem of HTTP time outs on [...] These two items combined, make this proposal an excellent candidate for running webservices in sciences like chemistry and biology. I understand the scenario, as I've written it's more general than scientific or biological computations (e.g send the input events from a UI widget placed somewhere to a remote service). Basically you'd like to do something like this: - retrieve a data scheme from an end point - send data to that end point - receive (also asynchronously) data from that end point Let's try to RESTify it in order to have a more general solution: - retrieving the data scheme is an operation on a particular node (a GET), so we don't need a particular action, just get it from the correct node, e.g. GET /nodename/schemata iq from=... to=... id=... type=set rest node=/nodename/schemata action=get xmlns=api:rest/ /iq - sending data is another operation on the node (the semantics of the operation on the data is given by the combination of the data and the node): POST /nodename payload iq from=... to=... id=... type=set rest node=/nodename action=post xmlns=api:rest header!-- optional --/header body!-- optional xml payload--/body rest/ /iq 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 supported by Ad-Hoc Commands. We think that this facilitates everything that is required to completely manage/control a remote process. As I already mentioned our approach is a very general one. The specs in the XEP is that open that it is of course possible to do what you suggest, for example see section 4.2 for getting the schemata. See 4.3 for sending data. - receiving the result depends on whether the operation is synchronous or not. If synchronous it's just the payload of the answer, and we can correlate them using the id in the iq/ stanza. Exactly. That's how we do it. If asynchronous the service should create a session on the client, by adding the session id to the headers of the subsequent asynchronous messages (this mechanism is application defined, other applications may create a specialized node or use other strategies for handling sessions) Yes, that's why the XEP uses Ad-Hoc Commands. Because it has already a session concept as you suggest here. In addition to this it is a widely supported XEP, we think that - with the very generic io data container in our specs - it is a friendly way to also support machine2machine parseable/readable and especially marshal-able services with it. As I already mentioned our approach is a very general one. The specs in the XEP is that open that it is of course possible to do what you suggest here: for example doing it in an asynchronous way there is the sessionid of Ad-Hoc Commands - especially Examples in section 4.4 and 4.2. I am aware that we continue the unofficial extension of Edrin, but having this as an official XEP will make it much easier to roll out XMPP-based webservices on a larger scale. Looking forward to hearing further comments! sure bye Thank you for your comments
Re: [Standards] Proposed XMPP Extension: IO DATA
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.html However, the initial version is erroneously missing some namespaces in the examples, therefore we append the current fixed version as PDF to the mail directly to the standards mailing list. Abstract: This specification defines an XMPP protocol extension for handling the input to and output from a remote entity. 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 be best implemented with the session based Ad-Hoc Commands XEP-0050. Thus, and as already suggested in Ad-Hoc Commands we describe an alternative data container IO DATA that can transport more complex data than Data Forms. The specification describes a way to discover the Schemata of the IO DATA input and output at runtime, too. Thus a client implementation can dynamically marshal an API for the input and output of a certain service. Johannes +1 This data container is really useful for a lot applications. Through my development of the Data Form Designer Suite for XMPP I've learned a lot about x-data and ad-hoc enhancement proposals. This showed me that ad-hoc commands which aren't emitted by humans might not need the overhead of static forms and structure. That's why this XEP is useful for all future machine-to-machine application and will largely ease development of them. Best of all there is already a working implementation so the concept has been more than proven. Cheers Tobias
Re: [Standards] XEP-0235: data forms?
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 support), data forms are a bit messy :) and a nice semantic XML is much easier to parse. In fact I'd say that Data Forms are good when you don't know in advance all the possible fields, or when you have complex input schemes that must be rendered in clients (e.g. muc or pubsub configuration). In the other cases as best practice I wouldn't abuse on them, in order not to be too much verbose (though we may find a way to binarize them ;)) Right, that's when we use data forms. But an authorization token is a small, atomic data unit, so I think it's best to use nice semantic XML in this case. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: IO DATA
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 Willighagen [EMAIL PROTECTED] wrote: 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 ;) 1. many different data types. This is particularly a problem in [...] 2. asynchronise calls. This is also a big limitation of our current tools. Call-by-reference does solve the problem of HTTP time outs on [...] These two items combined, make this proposal an excellent candidate for running webservices in sciences like chemistry and biology. I understand the scenario, as I've written it's more general than scientific or biological computations (e.g send the input events from a UI widget placed somewhere to a remote service). Basically you'd like to do something like this: - retrieve a data scheme from an end point - send data to that end point - receive (also asynchronously) data from that end point Let's try to RESTify it in order to have a more general solution: What is the particular benefit here of having a RESTful interface? In particular, do you think that we need to reference each action via a URI? Such as: xmpp:compute.example.com?io;node=foo;action=get;data=schema - retrieving the data scheme is an operation on a particular node (a GET), so we don't need a particular action, just get it from the correct node, e.g. GET /nodename/schemata iq from=... to=... id=... type=set I think you meant type='get' :) rest node=/nodename/schemata action=get xmlns=api:rest/ /iq It might be good to separately specify the node and the data type (in this case, the schema). - sending data is another operation on the node (the semantics of the operation on the data is given by the combination of the data and the node): POST /nodename payload iq from=... to=... id=... type=set rest node=/nodename action=post xmlns=api:rest header!-- optional --/header body!-- optional xml payload--/body rest/ /iq - receiving the result depends on whether the operation is synchronous or not. If synchronous it's just the payload of the answer, and we can correlate them using the id in the iq/ stanza. If asynchronous the service should create a session on the client, by adding the session id to the headers of the subsequent asynchronous messages (this mechanism is application defined, other applications may create a specialized node or use other strategies for handling sessions) iq from=... to=... id=... type=result rest xmlns=api:rest header session id= xmlns=api:sessionopen//session /header rest/ /iq Well, this is just a first attempt to brainstorm... The structure is much like HTTP, where we have actions, headers (for carrying optional metadata concerning the document) and the exchanged document, with all the semantics left to the application. In this way we have the same expressiveness of HTTP, with the advantage of a bidirectional asynchronous support as XMPP. I am not too much into XMPP myself, but hope the discussions on this mailing list will help us get the proposal in shape, because we really like to see this functionality. The example code from Johannes looks great, and eager to start using it. We are setting up webservices for metabolomics, where the data that needs to be passed around goes in the gigabytes, and where processing easily goes into the tens of minutes. 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. Keep us informed about the performance and the setup you use. Good question. Typically I think that computational processes might want to include binary blobs. The question is how best to do that -- e.g., a data/ element per XEP-0231 or a reference to a URI where the data can be retrieved via HTTP or FTP or XMPP or whatever. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: IO DATA
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 missing some namespaces in the examples, therefore we append the current fixed version as PDF to the mail directly to the standards mailing list. Feel free to send updated versions to me and I'll update that URL. Abstract: This specification defines an XMPP protocol extension for handling the input to and output from a remote entity. 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 be best implemented with the session based Ad-Hoc Commands XEP-0050. Thus, and as already suggested in Ad-Hoc Commands we describe an alternative data container IO DATA that can transport more complex data than Data Forms. The specification describes a way to discover the Schemata of the IO DATA input and output at runtime, too. Thus a client implementation can dynamically marshal an API for the input and output of a certain service. 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? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] Labeling Roster Items
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 gmail, delicious, and flickr. 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). But roster items aren't simple data types, they represent our relationships with people! and people often don't belong to just one group. Rather the people in our lives often belong to many different intersecting groups (my good friend caleb, is both part of the programmers in my life, and my close friends, and my child hood friends, and the people I play soccer with, and climbing). There doesn't seem to be an technical limitation in creating tags or labels for XMPP roster items, there are some questions to be answered about how to store the relations, and what semantics to use when querying them, but these aren't insurmountable. as an initial reference for XEP's that look / act similar there is * MetaContacts - http://www.xmpp.org/extensions/xep-0209.html * Annotations - http://www.xmpp.org/extensions/xep-0145.html My only worry is that both of these use the Storage protocol, and I question how easy it would be to form queries like 'retrieve me all the users with tags X and Y' Which might be out of band for this XEP but I suspect that queries like that might be powerful.
Re: [Standards] Labeling Roster Items
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 any sort of binning, since there is no group hierarchy stored in the roster (a group cannot exist without a contact in it, much like a tag can often not exist without at least one thing tagged). -Justin
Re: [Standards] Labeling Roster Items
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 contact may be in multiple groups. In fact, the grouping is more like tagging than any sort of binning, since there is no group hierarchy stored in the roster (a group cannot exist without a contact in it, much like a tag can often not exist without at least one thing tagged). Hmm so this problem is by and large in how Groups are implemented in the wild? That in and of itself might seem to be reason at least to create a new semantic grouping. Right now I'm struggling to find an number of clients that let me keep users in multiple groups, or at least give me ui to group in a tagging like behavior. ~ Anders -Justin
