Re: [Social-discuss] Languages -- let's make a web application

[Ted Smith]

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