Why the concern for shared hosting? I recently switched to Slicehost (a VPS provider) and it's about 1000x better than my previous shared hosting experience. There are no issues with running daemons on VPS. I honestly believe the hosting market will head this way with everything being hosted on separate virtual private servers. Prices will come down although paying $20/month for a 256M / 10GB HD / 100GB bandwidth where you have full admin rights is not a bad deal.
On Wed, Jun 18, 2008 at 7:25 PM, Bob Wyman <[EMAIL PROTECTED]> wrote: > 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 >>> >> >> >
