Backend Communication (e.g. REST API)

[balupton]

Current implementations:

• RESTAPI Plugin (supports CRUD, doesn't yet support uploads)
• Sync Plugin (supports only backend to backend)

Resources:

• Future of GUIs

[deitch]

What does a REST plugin for DocPad mean? What is the use case?

[balupton]

So a GUI can perform CRUD operations with DocPad over ajax. Will be out soon :)

[dwynne]

Is there a repo we can look at to see the direction this is heading in? I'm intrigued to know if this will handle physically writing files out? ie. Can I POST/PUT a document and have the static file created/updated on the server?

[neilbaylorrulez]

Hey David

It will handle definitely that and a whole lot more :)

The REST API is here: https://github.com/docpad/docpad-plugin-restapi

[dwynne]

Fantastic, thanks! Had a quick flick through the code and it's looking very promising!

[balupton]

One thing we should also consider is providing not only a REST/AJAX api for CRUD, but also a sockets based one as well, allowing us to move from polling data, to a pub/sub method of data. This has somewhat been proven to be possible via the sync plugin

On a completely seperate topic, it would be great if the GUIs we create could be agnostic to the backend. This could be implemented in one of these ways I think:

1. Have the different backends implement the same API - leaving the responsibilities to the backend providers (e.g. DocPad, Punch)
2. Have the different backends implement whatever APIs are best for them, then have the agnostic GUI provide proxies that serve as adapters for each backend provider - leaving the responsibility to the GUI authors

Not sure if the right solution is 1 or 2 or a combination of both. 1 makes sense from standardizing a particular API and moving forward fast (for instance with our rapid progress here with DocPad and the GUI) and then allowing others to follow. 2 makes sense from a longevity point of view in terms of it opens up the platform to other backends.

Personally, I think the quickest way forward would be to use 1 then follow up to 2. However, I'm open to having that countered.

/cc @laktek your thoughts?

[balupton]

Proceeded with this suggestion by splitting out the Inline GUI to https://github.com/webwrite/inlinegui and implementing a spec here for backend implementations https://github.com/webwrite/spec

Trying to figure out authentication (#21) and deployment now (#15)

[almereyda]

As discussion is not closed and any vision documents are lacking to be able to contribute to via Pull Requests, I am dumping some general thoughts to the topic here, as I may not be misunderstood for once:

---

When I see issues like Central user Database, User Authentication and Local User Database a strange feeling arrives regarding federated identity. Why do we see tendencies here to recentralize an aspect of an application?

Talking about the Unhosted, Offline First and noBackend approaches by remoteStorage.js and hood.ie. Yet again brewing their own soup. New buzzword: Front-End First.

Following discussions like Sync to non-commercial storage makes me wonder the importance of independent storage is not as prevailent as I believed.

A secure scuttlebutt , eventually routed by NDN and Level Replicate on the other side implement protocols close the work of the *ouchDB crowd. (Referred to as the ouch replication protocol).

I see DocPad's role here as the reference implementation for decoupled human interfaces. A way in helping to keep the dependency graph small for each component.

---

Why is it now that I can't replicate, say, from LevelDB running in IndexedDB, not even leveraging any other local PouchDB, to CouchDB or remoteStorage? Why can't we have data portability as simple as copying files?

For talking to the user's Dropbox account, you can use Dropbox.js, and there is a similar client-side library for GoogleDrive.

PouchDB acts both as an in-browser database engine, and a client for replicating data from and to a remote CouchDB instance with CORS enabled, which may be the user's own CouchDB server. Likewise, sockethub-client makes it easier to communicate with a Sockethub API which may be on the user's own server, and hoodie.js does the same for Hoodie's API.

All these libraries have a one-to-one relationship with a specific backend API. For PouchDB this is not such a limiting restriction, because there are quite a few software products that expose a CouchDB-compatible API. But as far as I know, only Sockethub itself exposes a sockethub-compatible API, and only Hoodie itself exposes a Hoodie-compatible API. That means that basing your app on them may allow the user to choose where they want their backend hosted, but in practice they do not have a free choice out of more than one backend software implementation.

Of course, Dropbox-js and the GoogleDrive JS library are even worse in that sense, because they only allow you to sync with per-user backend storage at one specific storage provider, so that's even more restrictive. That's why it is interesting to look at client-side libraries that try to be as generous as possible in the per-user backend they are compatible with.

via https://unhosted.org/practice/32/Client-side-libraries-for-per-user-backend.html

I like the definition of a webwrite spec, something similiar to writing remoteStorage or ouch (which they sometimes even just call JSON-over-HTTP), but closer to Hydra-style Hypermedia APIs.

But still, what is lacking to let APIs actually talk to each other, explain themselves and make the desired content flow? I'm yielding at the Federated Wiki's API now, which uses verbs like fork in a distributed manner (GitHub would dream of) that allows us to use the term federated.

GitHub is not the decentralized vision git itself is providing. From a wiki point of view (single point of view every point of view ) federation leads to a new way of http://wiki-allmende.rhcloud.com/view/wiki-version-control/view/wik-dvcs/view/semanticize-wik/view/socialize-wik/view/wik-architecture/view/wik-transport/view/wik-storage within a Chorus of Voices.

Another candidate to federate with is now also, next to TiddlyWikis (with Timelines) and any other Wiki, forkdb being used in wikidb for simple howto wikis.

Now, why can't I just fork everything into a federated wiki worksheet (IPython style) right now? The technology seems to be there.

---

But what we're lacking are the social protocols.

The whole point of a standardized protocol is to eliminate the need for centralized, proprietary protocols and solutions. On the Web we create common standards and protocols for that. We usually only let them compete before they become final specs to see what works best, and then continue with a single one that people agreed upon. (This is an over-simplified view of reality of course, but the general idea.)

via http://community.remotestorage.io/t/comparison-with-other-products/201/9.

Loomio aims at facilitating these conversations, and we're also trying to design these kinds of rhizomatic social activities in JSON-LD, but it remains hard. When do we know the competition is over? When do we start to cooperate on a truly global scale?

---

Basically what I'm asking is: How can we operate backend agnostic and abstract all possible use cases away to replicate anywhere while remaining adaptive to special environments and their certain needs? Where's the interoperable by design factor?

webwrite itself doesn't sound too far from ReadWriteWeb, i.e., but remains incompatible (WebID and stuff).