Since this conversation has gone kinda dead (and even the wiki, supposedly the center of attention, hasn't been updated recently), let's see about trying to foment some useful, if slightly tangential, conversation
( Read more... )
Well, for starters, RSS/ATOM everywhere. Besides a convenience factor, it's fast becoming one of the default ways of pushing textual data around, and can be used as a quick and dirty export, or lensed through many different tools (rss-to-e-mail, yahoo pipes, etc) to give people the freedom to do interesting things. One of my biggest beefs with LJ is that it is impossible to get an RSS feed of my friends page. I can get individual feeds for individuals, but that doesn't include locked posts, and throws away all the useful social mangement tools in LJ
( ... )
Definitely a sensible option for the "pull" side of the equation. Although the relationship of RSS and threading isn't clear to me yet -- the multi-dimensional aspect of the data needs to be clearer. All the RSS applications I can think of so far are essentially one-dimensional: a linear stream of messages. Do you know how to build a threaded structure and updates into that?
How about push? I can see a lot of applications (*especially* anything like CommYou), where you want prompt, efficient distribution of new data, so a push model would be very useful. I'm toying with the idea of seeing whether something could be built on XMPP/Jabber -- that seems to be where the momentum is right now.
One of my biggest beefs with LJ is that it is impossible to get an RSS feed of my friends page. I can get individual feeds for individuals, but that doesn't include locked posts, and throws away all the useful social mangement tools in LJ.Yep. This is a common problem, far as I can tell: relatively few
( ... )
Do you know how to build a threaded structure and updates into that?
Sadly, no. Current systems sometimes do multiple feeds, one for posts, one for comments. But, those tend to throw out context. Atom does have some fields that can bu purposed towards having a relationship between items (category, updated), and of course, is extensible. But just because the feed has the elements doesn't mean the destination can interpret them. May need to insert links right into the textual content, or use twitter's growing '@' reply convention.
How about push? Well, XML-RPC and Atom both have 'publishing' specs that can be engaged when a post is created to push the data elsewhere (webwise), but XMPP is a good choice, or some other way of connecting it to a realtime communicator that people are likely to have open anyhow. There's also e-mail subscription options.
relatively few systems marry RSS and authenticationThere's competing goals here. Much of RSS is used for openness and transparency, but there are plenty of places that do
( ... )
May need to insert links right into the textual content, or use twitter's growing '@' reply convention.
I don't love either option. Links directly in the text tend to lose semantic context. (Although I suppose we could create a microformat for that.) And the @ convention is too coarse-grained. It works for Twitter because that doesn't have real conversation threads, but it breaks down as soon as you try to do any sort of true threading.
Well, XML-RPC and Atom both have 'publishing' specs that can be engaged when a post is created to push the data elsewhere (webwise)
Really? I had no idea Atom had such a thing. I know RSS moderately well, but haven't dug into Atom much. I'll have to look into that.
Looking again at Atom (as the latest spec for feeds), they have an authentication element built in.
Even more interesting. Clearly I need to set aside some time to learn Atom...
CommYou is intended to be single server, right? So I assume you're designing a client-server protocol, while EJ is designing a server-server protocol, separate from how the server interacts with clients. I think that these should be collapsed into one protocol, but I'd believe that the optimizations are different
( ... )
Well, in the same sense as LJ -- that is, "single giant heterogeneous multi-cluster server farm". Monolithic, yes, but a long ways from a single machine. (At least, in the long run. Right at the moment it's a single machine, but I don't expect to even get out of alpha that way.)
More relevantly, even internally this *may* matter to me. As a matter of principle, I prefer internal APIs when I can have them -- it means that my APIs are honestly useful, at least for what I'm doing. So it is *possible* (although by no means certain) that I might use some of these protocols internally to my own system. That becomes more likely if, eg, I wind up hosting dedicated business servers for large companies, which want to have their own clusters but communicate in a well-controlled way with the rest of the world.
LJ does "new post by [user]" and "new comment on [thread]"Fascinating. I hadn't known that LJ had thread-specific feeds -- I don't think I've ever seen them in action. I'll have to look
( ... )
single giant heterogeneous multi-cluster server farm
Yes, that's what I meant. Though your point about internal APIs is good food for my thought.
I hadn't known that LJ had thread-specific feeds
I don't mean that it does RSS feeds. I'm talking about the "track this post" feature, which sends me email when interesting things happen.
the client starts up with a "what's new for me?" pull, and then registers a push handler.
So you've already come to the conclusion I'm advocating. If CommYou were a little farther along, I'd stop thinking about EJ and just wait. :)
q>Keeping track of what's new is a fairly expensive operationExpensive in what terms? Relatedly, what resources should we be considering scarce? Database queries? Bandwidth? Client-side processing of data? It seems like the protocol choice is largely choosing among these
( ... )
I'm talking about the "track this post" feature, which sends me email when interesting things happen.
Oh, I see. True, although it obviously wants a better channel for machine-to-machine comms.
If CommYou were a little farther along, I'd stop thinking about EJ and just wait. :)
Heh. Well, if you want to get in on the absolute ground floor, it's up and running. Doesn't *do* a huge amount yet -- I've got maybe 20-25% of the core features implemented, much less all the goodies -- but it's up to the point where it can be used for simple conversation. My current goal is to be "usable" by the end of May and starting to get "cool" by the end of June.
I've got a modest number of early adopters (maybe a dozen or so) kicking the tires and helping me figure out priorities; you're welcome to join in if you'd like. The alpha is open for the time being, although I might close the beta at some point, if I need the time to scale.
Expensive in what terms?DB size and access, mainly -- the number of records needed to track what the user is
( ... )
Actually, by the nature of the beast it's entirely self-signup. CommYou intentionally doesn't maintain its own accounts -- it's designed to leverage external social networks, and provide better conversation capabilities for them. Initially it's based on Facebook (mostly because there is so much room to improve Facebook), although other networks will be supported down the line.
Anyway, instructions for signing up are available on the company website. I encourage you to come play with it (feel free to friend me there, to hook into the conversations I'm starting). It's early days yet, so I'm leaving it open -- we've only got 1-2 dozen users yet, so I'm not worrying about locking it down at this point...
Comments 11
Reply
Definitely a sensible option for the "pull" side of the equation. Although the relationship of RSS and threading isn't clear to me yet -- the multi-dimensional aspect of the data needs to be clearer. All the RSS applications I can think of so far are essentially one-dimensional: a linear stream of messages. Do you know how to build a threaded structure and updates into that?
How about push? I can see a lot of applications (*especially* anything like CommYou), where you want prompt, efficient distribution of new data, so a push model would be very useful. I'm toying with the idea of seeing whether something could be built on XMPP/Jabber -- that seems to be where the momentum is right now.
One of my biggest beefs with LJ is that it is impossible to get an RSS feed of my friends page. I can get individual feeds for individuals, but that doesn't include locked posts, and throws away all the useful social mangement tools in LJ.Yep. This is a common problem, far as I can tell: relatively few ( ... )
Reply
Sadly, no. Current systems sometimes do multiple feeds, one for posts, one for comments. But, those tend to throw out context. Atom does have some fields that can bu purposed towards having a relationship between items (category, updated), and of course, is extensible. But just because the feed has the elements doesn't mean the destination can interpret them. May need to insert links right into the textual content, or use twitter's growing '@' reply convention.
How about push?
Well, XML-RPC and Atom both have 'publishing' specs that can be engaged when a post is created to push the data elsewhere (webwise), but XMPP is a good choice, or some other way of connecting it to a realtime communicator that people are likely to have open anyhow. There's also e-mail subscription options.
relatively few systems marry RSS and authenticationThere's competing goals here. Much of RSS is used for openness and transparency, but there are plenty of places that do ( ... )
Reply
I don't love either option. Links directly in the text tend to lose semantic context. (Although I suppose we could create a microformat for that.) And the @ convention is too coarse-grained. It works for Twitter because that doesn't have real conversation threads, but it breaks down as soon as you try to do any sort of true threading.
Well, XML-RPC and Atom both have 'publishing' specs that can be engaged when a post is created to push the data elsewhere (webwise)
Really? I had no idea Atom had such a thing. I know RSS moderately well, but haven't dug into Atom much. I'll have to look into that.
Looking again at Atom (as the latest spec for feeds), they have an authentication element built in.
Even more interesting. Clearly I need to set aside some time to learn Atom...
Reply
Reply
Well, in the same sense as LJ -- that is, "single giant heterogeneous multi-cluster server farm". Monolithic, yes, but a long ways from a single machine. (At least, in the long run. Right at the moment it's a single machine, but I don't expect to even get out of alpha that way.)
More relevantly, even internally this *may* matter to me. As a matter of principle, I prefer internal APIs when I can have them -- it means that my APIs are honestly useful, at least for what I'm doing. So it is *possible* (although by no means certain) that I might use some of these protocols internally to my own system. That becomes more likely if, eg, I wind up hosting dedicated business servers for large companies, which want to have their own clusters but communicate in a well-controlled way with the rest of the world.
LJ does "new post by [user]" and "new comment on [thread]"Fascinating. I hadn't known that LJ had thread-specific feeds -- I don't think I've ever seen them in action. I'll have to look ( ... )
Reply
Yes, that's what I meant. Though your point about internal APIs is good food for my thought.
I hadn't known that LJ had thread-specific feeds
I don't mean that it does RSS feeds. I'm talking about the "track this post" feature, which sends me email when interesting things happen.
the client starts up with a "what's new for me?" pull, and then registers a push handler.
So you've already come to the conclusion I'm advocating. If CommYou were a little farther along, I'd stop thinking about EJ and just wait. :)
q>Keeping track of what's new is a fairly expensive operationExpensive in what terms? Relatedly, what resources should we be considering scarce? Database queries? Bandwidth? Client-side processing of data? It seems like the protocol choice is largely choosing among these ( ... )
Reply
Oh, I see. True, although it obviously wants a better channel for machine-to-machine comms.
If CommYou were a little farther along, I'd stop thinking about EJ and just wait. :)
Heh. Well, if you want to get in on the absolute ground floor, it's up and running. Doesn't *do* a huge amount yet -- I've got maybe 20-25% of the core features implemented, much less all the goodies -- but it's up to the point where it can be used for simple conversation. My current goal is to be "usable" by the end of May and starting to get "cool" by the end of June.
I've got a modest number of early adopters (maybe a dozen or so) kicking the tires and helping me figure out priorities; you're welcome to join in if you'd like. The alpha is open for the time being, although I might close the beta at some point, if I need the time to scale.
Expensive in what terms?DB size and access, mainly -- the number of records needed to track what the user is ( ... )
Reply
That would be cool. Maybe I'll learn to be more active than I am on LJ. I'm bergey at alum mit edu.
Reply
Anyway, instructions for signing up are available on the company website. I encourage you to come play with it (feel free to friend me there, to hook into the conversations I'm starting). It's early days yet, so I'm leaving it open -- we've only got 1-2 dozen users yet, so I'm not worrying about locking it down at this point...
Reply
Leave a comment