librelist archives

« back to archive

Fwd: Accessing foreign (public) storage via remoteStorage.js

Fwd: Accessing foreign (public) storage via remoteStorage.js

From:
Niklas Cathor
Date:
2012-09-17 @ 09:57
(sorry, posting to remotestorage list didn't work with other email)

---------- Forwarded message ----------
From: nil <nil.niklas@gmail.com>
Date: Mon, Sep 17, 2012 at 11:43 AM
Subject: Accessing foreign (public) storage via remoteStorage.js
To: unhosted <unhosted@googlegroups.com>, remotestorage@librelist.com


Currently remoteStorage.js only provides methods for accessing your
own storage. Apps that want to access foreign storage need to cook
their own soup.

As accessing other people's published data is an integral part of so
called "social" apps, remoteStorage.js should provide ways to interact
with the data, in a similar way that it interacts with the user's own
data. That is to say, provide local caching, synchronization and
data-specific logic (i.e. modules).

So to me the most logical place to expose access functions for foreign
storage is the module definition.
Right now a module skeleton looks somewhat like this:

  remoteStorage.defineModule('beers', function(privateClient, publicClient)
{
    return { exports: { ... } }
  });

I hereby propose to add another parameter:

  remoteStorage.defineModule('beers', function(privateClient,
publicClient, foreignClient) {
    return { exports: { ... } }
  });

The foreignClient would pretty much expose the same methods as the
baseClient instances, except that all methods will additionally
receive a reference to the storage that should be accessed.

Example:

  This is how you get an object now, through the baseClient:
    privateClient.getObject("favourite-beer");

  This is how you then would get someone else's public "favourite-beer"
object:
    foreignClient.getObject(userRef, "favourite-beer");

Now what I'm not entirely sure about is what that object will be, that
I called "userRef". A while ago I would have said: the useraddress.
However with the storage-first option the useraddress becomes
optional.
So I could imagine, that for maximum compatibility the object could be
something like this:

  { userAddress: "me@having.beer" }

which would trigger a webfinger discovery, OR

  { storageHref: "https://having.beer/storage/me", storageType: "..." }

which would just use that information directly.

Before I go into actually implementing any of that, I hope lots of
people have thoughts & feedback on this.

cheers,

Niklas Cathor

Re: [remotestorage] Fwd: Accessing foreign (public) storage via remoteStorage.js

From:
Michiel de Jong
Date:
2012-09-17 @ 10:14
hi!

i would decouple it from webfinger. the contacts module should
probably have a way to generically discover the storage root of a
contact (which could be a live cross-origin webfinger lookup, or
something else, that's out of scope then).

the beer module would then have a function that takes a storage root
as an argument, and tells its foreign base client to sync the
appropriate data

On Mon, Sep 17, 2012 at 11:57 AM, Niklas Cathor <niklas@unhosted.org> wrote:
> (sorry, posting to remotestorage list didn't work with other email)
>
>
> ---------- Forwarded message ----------
> From: nil <nil.niklas@gmail.com>
> Date: Mon, Sep 17, 2012 at 11:43 AM
> Subject: Accessing foreign (public) storage via remoteStorage.js
> To: unhosted <unhosted@googlegroups.com>, remotestorage@librelist.com
>
>
> Currently remoteStorage.js only provides methods for accessing your
> own storage. Apps that want to access foreign storage need to cook
> their own soup.
>
> As accessing other people's published data is an integral part of so
> called "social" apps, remoteStorage.js should provide ways to interact
> with the data, in a similar way that it interacts with the user's own
> data. That is to say, provide local caching, synchronization and
> data-specific logic (i.e. modules).
>
> So to me the most logical place to expose access functions for foreign
> storage is the module definition.
> Right now a module skeleton looks somewhat like this:
>
>   remoteStorage.defineModule('beers', function(privateClient, publicClient)
> {
>     return { exports: { ... } }
>   });
>
> I hereby propose to add another parameter:
>
>   remoteStorage.defineModule('beers', function(privateClient,
> publicClient, foreignClient) {
>     return { exports: { ... } }
>   });
>
> The foreignClient would pretty much expose the same methods as the
> baseClient instances, except that all methods will additionally
> receive a reference to the storage that should be accessed.
>
> Example:
>
>   This is how you get an object now, through the baseClient:
>     privateClient.getObject("favourite-beer");
>
>   This is how you then would get someone else's public "favourite-beer"
> object:
>     foreignClient.getObject(userRef, "favourite-beer");
>
> Now what I'm not entirely sure about is what that object will be, that
> I called "userRef". A while ago I would have said: the useraddress.
> However with the storage-first option the useraddress becomes
> optional.
> So I could imagine, that for maximum compatibility the object could be
> something like this:
>
>   { userAddress: "me@having.beer" }
>
> which would trigger a webfinger discovery, OR
>
>   { storageHref: "https://having.beer/storage/me", storageType: "..." }
>
> which would just use that information directly.
>
> Before I go into actually implementing any of that, I hope lots of
> people have thoughts & feedback on this.
>
> cheers,
>
> Niklas Cathor
>
>

Re: [remotestorage] Fwd: Accessing foreign (public) storage via remoteStorage.js

From:
Niklas Cathor
Date:
2012-09-17 @ 10:50
On Mon, Sep 17, 2012 at 12:14 PM, Michiel de Jong <michiel@unhosted.org>wrote:

> hi!
>
> i would decouple it from webfinger. the contacts module should
> probably have a way to generically discover the storage root of a
> contact (which could be a live cross-origin webfinger lookup, or
> something else, that's out of scope then).
>

Right, that would mean something like this:

  remoteStorage.claimAccess({
    contacts: 'r',
    documents: 'rw'
  });

  var contact = remoteStorage.contacts.search({ fn: "some name" })[0];
  var documents = remoteStorage.documents.listForeign(contact);

In this case "contact" is what I called userRef in the last post.

The contacts module then could also allow searching useraddress.net or
something like that to lookup people you don't have information about yet.


> the beer module would then have a function that takes a storage root
> as an argument, and tells its foreign base client to sync the
> appropriate data
>
> On Mon, Sep 17, 2012 at 11:57 AM, Niklas Cathor <niklas@unhosted.org>
> wrote:
> > (sorry, posting to remotestorage list didn't work with other email)
> >
> >
> > ---------- Forwarded message ----------
> > From: nil <nil.niklas@gmail.com>
> > Date: Mon, Sep 17, 2012 at 11:43 AM
> > Subject: Accessing foreign (public) storage via remoteStorage.js
> > To: unhosted <unhosted@googlegroups.com>, remotestorage@librelist.com
> >
> >
> > Currently remoteStorage.js only provides methods for accessing your
> > own storage. Apps that want to access foreign storage need to cook
> > their own soup.
> >
> > As accessing other people's published data is an integral part of so
> > called "social" apps, remoteStorage.js should provide ways to interact
> > with the data, in a similar way that it interacts with the user's own
> > data. That is to say, provide local caching, synchronization and
> > data-specific logic (i.e. modules).
> >
> > So to me the most logical place to expose access functions for foreign
> > storage is the module definition.
> > Right now a module skeleton looks somewhat like this:
> >
> >   remoteStorage.defineModule('beers', function(privateClient,
> publicClient)
> > {
> >     return { exports: { ... } }
> >   });
> >
> > I hereby propose to add another parameter:
> >
> >   remoteStorage.defineModule('beers', function(privateClient,
> > publicClient, foreignClient) {
> >     return { exports: { ... } }
> >   });
> >
> > The foreignClient would pretty much expose the same methods as the
> > baseClient instances, except that all methods will additionally
> > receive a reference to the storage that should be accessed.
> >
> > Example:
> >
> >   This is how you get an object now, through the baseClient:
> >     privateClient.getObject("favourite-beer");
> >
> >   This is how you then would get someone else's public "favourite-beer"
> > object:
> >     foreignClient.getObject(userRef, "favourite-beer");
> >
> > Now what I'm not entirely sure about is what that object will be, that
> > I called "userRef". A while ago I would have said: the useraddress.
> > However with the storage-first option the useraddress becomes
> > optional.
> > So I could imagine, that for maximum compatibility the object could be
> > something like this:
> >
> >   { userAddress: "me@having.beer" }
> >
> > which would trigger a webfinger discovery, OR
> >
> >   { storageHref: "https://having.beer/storage/me", storageType: "..." }
> >
> > which would just use that information directly.
> >
> > Before I go into actually implementing any of that, I hope lots of
> > people have thoughts & feedback on this.
> >
> > cheers,
> >
> > Niklas Cathor
> >
> >
>