On Sun, 2010-03-28 at 13:44 -0400, Matt Lee wrote: > I don't believe that a desktop application should be the initial focus > of this. > > This kind of application belongs in a browser right now, so people can > access it from their phone, their office, their laptop, their iPad, > whatever.
Their mobile computer (what you referred to as "phone"), office computer, and laptop computer can all run software (the iPad can't :-( ). There's no reason not to write a portable application that interfaces with a persistent server or network. I don't think anyone is arguing that GNU Social should exist only as a desktop application. Personally, I think it should exist as a core daemon that handles "real work", and as various interfaces. One interface could be a desktop application, one could be a PHP-based web application, one could be a Replicant application, one could be a daemon that sent and received SMS messages, etc.. This limits the web hosting space to what can run non-privileged programs in whatever language the GNU Social core is written in. I'm not sure what the constraints of "commodity webhosting" as you define it, and I'm not sure how you're determining those constraints. I hope that this limitation is not outside those constraints, but if it is, we have to examine if that is worth it or not. From your later email: > There's no reason at all why I can't set up a server, publish my > social activity to my own server and have my friends pull that > information in. Presumably you're discussing GNU social running on a personal computer? I'll assume that's the case. The problem with using PHP as the language for the GNU Social core here is that users have to set up a GLAMP stack, an RDBMS, and GNU Social. Then, to use it, they need to use a web browser. This is non-trivial to set up in a secure, maintainable way. In contrast, a modular, non-PHP GNU Social would require setting up the GNU Social core daemon and whatever interface you chose. The only configuration difference for a desktop interface would be the core server it points at. From your email in the "Which framework?" thread: > What's the backend? The backend needs to be PHP too, because the user > needs to be able to run their own backend, on their own $1 hosting > account. The user doesn't need to be able to run the backend on their own $1 hosting account if the system is P2P enough - they can just run it on their personal computer. If the user wants centralized persistence, they could install a GNU Social caching system on their $1 hosting account. If the user wants decentralized persistence, they just trust the p2p network. I'm also not sure what the ethical ramifications are of promoting a system wherein users are dependent on hosting providers to run their software - isn't that SaaS? That also shoots any crypto-based security GNU Social would want to have, because the hosting provider can just extract the key from memory. I don't think that the sort of "heavy computing is only for specialized companies" attitude is what GNU Social should promote. If the reason why you want GNU Social to run on commodity webhosting is that you want every user to run a persistent node, I don't see why a p2p personal-computer-oriented daemon is the wrong way to go.
signature.asc
Description: This is a digitally signed message part
