- From: Nick Jennings <nick@silverbucket.net>
- Date: Sat, 1 Jun 2013 22:41:01 +0200
- To: Andreas Kuckartz <A.Kuckartz@ping.de>
- Cc: public-fedsocweb <public-fedsocweb@w3.org>
- Message-ID: <CAJL4WtaxNCsJkH+=W5Ymjs7QgU-rNTHuHhs=LQGcq2p48jhzCg@mail.gmail.com>
On Sat, Jun 1, 2013 at 9:26 PM, Andreas Kuckartz <A.Kuckartz@ping.de> wrote: > Nick Jennings: > > I say it's not really about the protocol(s), it's about our approach in > > developing open alternatives for end-users. > > That is how I understand this approach: > > * Create some kind of glue which can be used to connect different kinds > of FSW nodes > > Either connect the nodes directly (more difficult) or abstract away the protocol specifics from the client application, while still having the interaction be essentially client-server (more easily accomplished). Federating two server nodes together, from two separate projects, brings up a lot of questions about what that actually means and in the end I think it may only make sense for a very small subset of data from each of the separate projects. (ie. sending messages back and forth), but not "native-like" interaction between users of separate projects. > * That reduces the amount of work required for the different FSW > projects to collaborate > > Yes, as long as their APIs and protocols are sound, and they allow third-party interaction, then I think we can make things work. Authentication is the big issue here, but solvable and there are work-arounds. Closing off an API is a big danger, though, sites like Twitter seem to be closing off more and more. For open alternatives, this isn't really an issue. > * Make the software created by FSW projects more modular > Yes, I think it makes sense to abstract away as much of the protocol specifics as early as possible. So, client-facing interfaces, although perhaps originally designed by one project, could theoretically be used in other contexts with similar types of data. For example. Developer A makes an awesome twitter client, using an abstraction layer for any and all protocol specifics. Let's say some new twitter-esque open alternatives comes on the market. That awesome twitter client could easily leverage the new site with very little change to the application. Correct? > Yes I think you've summed it up more or less.
Received on Saturday, 1 June 2013 20:42:00 UTC