Itay Neeman wrote: > My thoughts are inline. > > On Apr 10, 2008, at 10:11 PM, Peter Saint-Andre wrote: > >> Last week after the groupchat I chatted a bit with Ralph Meijer about >> blog integration. Assuming that folks publish to PEP nodes hosted at >> their bare JIDs (see XEP-0163), we discussed a few possibilities (Ralph, >> correct me if I'm missing anything): > > I am a bit worried about the usage of PEP instead of vanilla PubSub. The > reason is the "One Publisher Per Node" limitation > (http://www.xmpp.org/extensions/xep-0163.html#approach-publisher), which > renders a lot of the solutions here problematic (except #3), as others > could not post comments through PubSub.
I think your blogging software would be the publisher. You would give it your XMPP credentials and it would publish as you. The PEP approach is not really necessary -- in part PEP is there to help with discovery (e.g., my mood is found at my JID). But for blogging I (or my blogging service/software) can put an alternate link in the HTML head at the blog site and then you can discover where my pubsub node is hosted. So I tend to agree with you that pubsub is more appropriate here than PEP. >> 1. I host one node for my entries (each item is an entry) and one node >> for comments (each item is a comment). This requires a way for the >> comment items to reference the entry items. > > This is similar to #2, in that it requires us to define some syntax on > how to relate from one published item to another (or in general how to > "link" to a pubsub item). However, it does require two nodes per blog > instead of one, so it seems a bit unnecessary. Also, because there is > only "one node per namespace" (per the PEP spec), it is unclear to me > how in PEP you can subscribe to both nodes at once. In vanilla PubSub, > you could just create a "blog" collection node which hosts these two > nodes, but I am not sure this is true in PEP, though I am probably wrong. Further thought reveals to me that this doesn't really matter -- you can have separate entry and comment nodes as most people do now. But it's too bad that there the blog folks have not defined separate rel values for entries and comments. >> 2. I host a single node for my blog. Both entries and comments get >> published to the node, and an item can be an entry or a comment. This >> requires some syntax in the payload format to differentiate entries from >> comments (e.g., it can't be plain Atom). > > This is the easiest to implement, but shifts some responsibility to > clients to parse whether it is not only a "blog"-like message (based on > the node), but also to parse the actual message and find out whether it > is an entry or a comment. Hmm, yeah. >> 3. I host a node only for my entries. If you want to comment, you >> publish it at your own comments node. This requires cross-referencing >> between my entries and your posts. > > By far the hardest, but in a way, the best and most revolutionary. Many > websites, even today, dislike the "comment" system, in that it localizes > discussion rather than distribute it. This solves that problem. However, > a lot would need to be invented: > > 1. How to notify the entry publisher that a comment has been posted. > 2. How clients can be notified that a comment has been posted. > 3. How clients can fetch those comments without subscribing to the other > JID if they don't want to. Yeah. I like the general idea, but much work is involved and it depends on more significant deployment of pubsub. >> 4. I host one node for each post; the first item published to the node >> is the entry and subsequent items are comments. > > This really pollutes the namespace and makes things very difficult to > maintain, I think. Also, it suffers the most out of the lack of > collection nodes in PEP, though again, I am probably wrong about this. Yes I think this is ugly. >> None of these approaches will work well if I have multiple blogs. To >> solve that problem I'd need to have multiple nodes, one (or two) for >> each blog. > > If there are collection nodes in PEP, you could simply have a "blogs" > node, of which all your other nodes are children of. If not, however, > you are correct, though it is not such a big problem, just like today > people subscribe to multiple RSS feeds. > > Some more problems I see with using PEP instead of PubSub: > > 1. It can become very difficult to associate the online blog data with > the PEP data. The Wordpress plugin would need to both publish to the > entry node upon new entries, and also subscribe to some comment node and > push comments, for example. On second thought, this is not more > complicated than vanilla PubSub. > > 2. The one-publisher-per-node limitation needs to be seriously taken > into consideration. > > 3. We are limited in the complexity of our node hierarchies. For > example, Jehan (who is on vacation this week) wrote up a sample > hierarchy given his experience with the Wordpress Pubsub plugin, and > I'll reproduce it here: > > "There should be one single node with a given tree inside: a leaf node > for the > posts (people can subscribe to this one to get only the posts); a container > node for the comments (people can subscribe here to receive all > comments) with > inside a new leaf node for the comments of every new post (people can > subscribe to a specific post once it has been published to get comments > only > on this post). > > node -> posts (leaf) > -> comments (Collection) -> post_1 > -> post_2 > -> post_3 > ..." > > Whether or not this is better, I am not sure, but it certainly doesn't > pollute the namespace, and solves the multiple blogs problem. > > All in all, I like #3 the best, because I think it is the most social. > It takes the goodness of Twitter - the locality of a message, namely, it > is local to its author, and creates a distributed "blogosphere", which > still has connections. Yeah, I like that too, but it seems like something for the future. However I think in general that we'll want to link pubsub items (for a wide variety of use cases, not just blogging/comments/SNA stuff) so we'll need to define that anyway. > These are of course just my thoughts, so please tell me where I am wrong :) Thanks for moving the conversation along. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
