On 05/20/2008 10:38 AM, JabberForum wrote: > Blaine Cook;375 Wrote: >> I disagree. My point is that if the spec allows using HTTP URIs as >> PubSub >> nodes (it does), then you can write them the same. If they produce the >> same >> content, then they are the same, just over different transports. By >> making >> the nodes and urls equivalent, the accessibility for developers writing >> code >> against APIs increases dramatically. >> > > Maybe. I don't really understand, in fact but you seem to have a > precise idea of what you mean. So do you say that you can subscribe to > an XMPP node by clicking on a http url? HTTP and XMPP are separate tcp > protocols and unless you propose to access XMPP through an HTTP layer, I > don't really understand how you make an XMPP url with an http url. Could > you explain me this please, because maybe there is a very interesting > point here that I don't manage to get. :-)
He is saying that the NodeID would look like an HTTP URL. Now if you want to identify that Node ID as an XMPP URI, it would be some long string with xmpp: at the front, followed by the JID of the pubsub service, followed by the NodeID (which just happens to look the same as the HTTP URL at which you can get the same content, but suitably escaped). >> Not true. I've written dynamic PubSub handlers in Ruby (i.e., PubSub >> handlers that could support query strings), and it's easy enough to do >> so in >> any language. If you're accepting tags in some other form, e.g. <field >> />, >> then you're writing a dynamic PubSub handler anyways. >> > > I did not say it was not possible (of course it is) and that it did not > exist (though I didn't know, this is nice), but that it was not a > specification (of course I may be wrong. I have not read all the XMPP > specs, far from a little part even). > And for me having a specification helps to spread a technology. Anyway > dynamic pubsub is "less" important to be standardized though, because it > is server-side only. So you can implement it without wondering whether > some client would implement it too, etc. as it will work anyway > transparently on a client point of view. I don't think that category or tagging methods need to be defined in XEP-0060 -- that's something that people can build on top of the primitives in XEP-0060. For example that's what Bob did back in the old pubsub.com days. >> See the debate of WS-* to REST. Currently the protocol has support for >> this, >> but uses URLs (!) to define keyword semantics. The example given in the >> spec >> is: >> >> <field var='http://shakespeare.lit/search#keyword' >> type='text-single' >> label='Keyword to match'/> >> > > I don't really know this debate. I will make some searches. If you have > interesting links, don't hesitate too. > >> Moreover, XEP-0060 is 43,103 words long, which translates to about 172 >> pages >> of printed text. The chances of a keywording system being added to a >> PubSub >> architecture are pretty slim, I have to say. It's better to just accept >> the >> fact that usage will be diverse and let people develop their own >> methodologies for handling these things. >> > > For me, the size of the XEP should not be a brake for enhancing it. > First because you may make a second XEP related to it for enhanced use > case. Also because this is not like a compact text and it is very easy > to read with the summary (a technical text well structured is not to be > read like a story book, you can read some parts very fast, jump over > others, etc.). And I think some parts of this XEP can be enhanced > anyway, and maybe completely transform, etc. > > And finally for this, yes a specification is definitely useful because > it cannot be just implementation dependent. For the dynamic node url, > yes you can leave people develop their own methodologies, as I said, > because it is server side. > > But for a system of powerful indexing/search/subscription by tag (or > other field values), there is also a client-side implementation (because > if your server leaves the possibility for extended search but that your > client does not know how to make it, there is no use, unless you want > people to directly type XML). So there needs to be a common > specification, unless you want dozens of different implementation all > not-compatible for node/item indexing... Sure, feel free to write up a proposal. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
