Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove concrete application examples from API #30

Open
tobiastom opened this issue Oct 30, 2013 · 11 comments
Open

Remove concrete application examples from API #30

tobiastom opened this issue Oct 30, 2013 · 11 comments
Labels

Comments

@tobiastom
Copy link
Contributor

Right now inside the API.md there is a concrete example about building a distributed social network with GDS.

IMHO this is way to specific. For me GSD is a concept to install and delete applications and have them communicate with each other. GDS should only define the API between applications on one GDS node.

Connections to other GDS nodes should never be defined by this protocol.

To get back to the distributed social network example in API.md, there could be a GDS application that implements the tent protocol to archive that. One application at a time.

@lukasbestle
Copy link
Member

APIs between multiple GDS nodes are important, because there are multiple ways to implement each task on the server (let's take a shared calendar: if every app defines its own protocols, this will most likely fail).

@tobiastom
Copy link
Contributor Author

I completely agree, but we really should not throw away all the great work that was done with CalDAV, CardDAV and e.g. XMPP.

Again: I think we should define how the applications run on the server, now what they are running.

@lukasbestle
Copy link
Member

Of course, we should use as much existing protocols as possible.
Still, there are basic protocols we need to define and make available to all application such as discoverability.

@tobiastom
Copy link
Contributor Author

Like intends: definitely yes. What else do you think we need?

Am 30.10.2013 um 15:00 schrieb Lukas Bestle [email protected]:

Of course, we should use as much existing protocols as possible.
Still, there are basic protocols we need to define and make available to all application such as discoverability.


Reply to this email directly or view it on GitHub.

@janl
Copy link

janl commented Oct 30, 2013

On that note, http://sockethub.org seems to be a nice bridge to protocols

@augustl
Copy link
Contributor

augustl commented Oct 30, 2013

I agree. GDS isn't ownCloud. :) The default GDS implementation we create can come bundled with some apps, batteries included, Android style. But as much as possible should be replaceable. Perhaps we can go as far as having the UI for managing permissions use protocols and something intent-like (so the system knows which app that implements "calendar" and can prompt the user for which app to open if there are multiple "calendar" intent apps).

@tobiastom
Copy link
Contributor Author

Exactly. I could not agree more

@augustl
Copy link
Contributor

augustl commented Oct 30, 2013

Just to throw it out there, perhaps GDS apps should be able to communicate and use intents for non-GDS apps. Then the only thing GDS helps with is a dashboard for your apps, installation, etc.

https://en.wikipedia.org/wiki/Web_Intents

@tobiastom
Copy link
Contributor Author

It might even be an option to have even all GDS applications on one server only communicate via intends (or WebActivities).

@bastianallgeier
Copy link
Contributor

Just a question. Wouldn't it make sense to start writing down ideas for protocols or APIs. Pretty much like the hoodie guys do: http://nobackend.org/dreamcode.html

I think it would be much easier to discuss that.

@augustl
Copy link
Contributor

augustl commented Oct 30, 2013

@bastianallgeier I agree. Seems the consensus is a protocol driven approach. Perhaps a wiki is good for this, where we can throw around suggestions of various sets of protocols, where the set contains existing protocols and any new protocols that might need to be invented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants