On Wed, Jun 18, 2008 at 4:52 PM, Blaine Cook <[EMAIL PROTECTED]> wrote: > XRDS for this seems like massive overkill. > Whatever happened to good 'ol <link rel>? > It works fantastically for RSS feeds, which are > alternate representations of presented data, > just like messaging endpoints.
I think we may risk over using "good 'ol <link rel>". There is an issue here of "separation of concerns" or proper modularization. While <link rel> might "work", it does not seem right to rely on this mechanism for all links to all resources -- no matter how indirectly they may be related to the page in which they are found. I suggest that <link rel> should really only be used to link to resources that have a particular direct relationship to the HTML page in which the links are found. Links to Atom or RSS syndication files are typically links to alternative representations of the HTML files in which they are found and thus would fit the rule that I suggest. The JID that should be used in sending a message to the "owner" of a page is only indirectly related to an HTML page itself. Thus, it seems reasonable to use a mechanism which is explicitly intended to store links to persons or things with identity -- i.e. the XRDS file. Today, there aren't many things that get put in XRDS files. The result is that XRDS files often seem over designed for the limited purpose of providing links to OpenID services, etc. However, I think we'll find in the future that users will have a need to associate a broad set of linked resources to their identities. As this set of commonly linked resources grows, it will become less and less reasonable to stuff them all into HTML embedded <link rel>s. It should also be noted that it is quite likely that in many applications, XRDS files won't actually be maintained as static files on disk. They will, in fact, be generated on-demand and as a result will be able to accommodate potentially changing data. (my XRDS file might contain a link to the resource that describes my current location...) Forcing links to be stored in HTML would have the effect of discouraging the use of dynamic sets of links and, even if implemented via various templating systems, the use of dynamically changing links in HTML files would tend to make a mess of caching schemes -- even though the changes are not related to the HTML content itself. Use <link rel> for what it was intended to be used: Links to resources which are related to the containing HTML page. Use XRDS files for links that relate to things which have identity. bob wyman > On Wed, Jun 18, 2008 at 11:58 AM, Chris Messina <[EMAIL PROTECTED]> > wrote: > >> Presume that I have a URL of my own, given a recipient URL, I want to be >> able to send a message "at it" and have it be received on the other end, and >> be routed properly, based on the recipient's rules. As the sender, I just >> want to be able to send a message and know that the recipient should receive >> it. >> >> This parallels having a "from" email address and sending it "to" a >> recipient email address. But in this case we're replacing email as the >> identifier with a URL. >> > > Steve Ivy and I kicked around some ideas last week. They're recorded on the > DiSo project blog here: > http://diso-project.org/wiki/messaging-brainstorming > > >> So if I self-identify as http://twitter.com/factoryjoe and I want to send >> a message to http://twitter.com/redmonk, if on that endpoint is a >> discovery document that suggests where to send messages and how to sign them >> so that the messages will be received and not rejected outright, I think >> we're getting somewhere. >> > > Also, people don't self-identify as URLs. The OpenID experiment seems to > have proven this, as the consensus seems to be around using email addresses > (or email address-like identifiers) as OpenID identifiers. > > >> I see no reason not to use ATOM or XMPP for this, except that XMPP doesn't >> work well with today's shared hosting environments. Perhaps we use XRDS >> discovery to point to an XMPP endpoint and then offer a fallback ATOM >> endpoint in the case that XMPP would fail? >> > > I still question the requirement that this stuff run in a dreamhost-like > environment, where you don't have access to run daemons, and to that end can > only offer that the HTTP form of messaging should be a degraded form of > XMPP, not the primary mechanism. > > XRDS for this seems like massive overkill. Whatever happened to good 'ol > <link rel>? It works fantastically for RSS feeds, which are alternate > representations of presented data, just like messaging endpoints. > > >> You know that I'm against inventing unnecessarily -- which is why I >> pointed out this microblogging effort. It might not be the way to do it, but >> it gives us an example of someone's thinking that's actually been >> implemented and gives us something to build against. >> > > I appreciate the effort, but frankly, Twitter exports all the microblogging > information using a combination of already-available standards; Atom (maybe > hAtom?), hCard, etc. Why on earth would we seek to re-implement Atom when a > simpler approach satisfies the needs? > > >> >> Chris >> >> >> On Wed, Jun 18, 2008 at 11:33 AM, Eran Hammer-Lahav <[EMAIL PROTECTED]> >> wrote: >> >>> My question is given the simplicity of microblogging, assuming we get >>> an activity stream spec/solution figured out, wouldn't it implicitly solve >>> the "open" microblogging need? Given that a microblogging "action" is the >>> same as its "notification", it looks to me to be a specialized subset of >>> activity streams. >>> >>> EHL >>> >>> >>> >>> On 6/18/08 11:22 AM, "Stephen Paul Weber" <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>> > Is this something we could/should implement? How could we make it more >>> > "DiSo" friendly? (Sorry I need to read it over but haven't had a chance >>> > yet). >>> >>> I have said this to Steve privately, and I will now say it publicly: >>> reinventing messaging protocols over HTTP is a *bad* idea. We have >>> protocols (more than one, two very popular ones), *open* *standard* >>> protocols (yes, I'm looking square at SMTP and XMPP - as well as NNTP, >>> which is less applicable) that do messaging *well* *really well* they >>> were, well, *built for it*. They have faced the problems and improved >>> to solve them. They stand the test of time, *do* the job, and are >>> *widely* implemented. Unless there is a use case that one of the >>> existing standards cannot meet (which I doubt more each time I >>> consider this), I see no reason to invent anything, only to build >>> tools to use what we have. >>> >>> Furthermore, reinventing content pushing over HTTP is a *bad* idea. >>> There are several *open* and *implemented* (although less widely than >>> messaging protocols) standards for pushing content *even specifically >>> post or blog-type content* over HTTP. XML-RPC and AtomPub, to name >>> two. >>> >>> (Yes, this is a variation on my "please don't invent anything" rant.) >>> >>> -- >>> - Stephen Paul Weber (Singpolyma) >>> >>> Web: http://singpolyma.net/ >>> Twitter: http://twitter.com/singpolyma >>> IM: [EMAIL PROTECTED] >>> >>> >>> >>> >>> --~--~---------~--~----~------------~-------~--~----~ >>> You received this message because you are subscribed to the Google Groups >>> "DiSo Project" group. >>> To post to this group, send email to [EMAIL PROTECTED] >>> To unsubscribe from this group, send email to >>> [EMAIL PROTECTED] >>> For more options, visit this group at >>> http://groups.google.com/group/diso-project?hl=en >>> -~----------~----~----~----~------~----~------~--~--- >>> >>> >> >> >> -- >> Chris Messina >> Citizen-Participant & >> Open Source Advocate-at-Large >> factoryjoe.com # diso-project.org >> citizenagency.com # vidoop.com >> This email is: [ ] bloggable [X] ask first [ ] private >> > >
