Re: Hypermedia acid test

The "simultaneously" part was meant to say that the client is able to
browse itself by acting as a server at the same time.

I think we can take connection problems out of the picture for the sake of
this test.
On Apr 21, 2015 6:53 AM, "Dietrich Schulten" <ds@escalon.de> wrote:

> Hi Martynas,
>
> you want to prove if an architecture uses hypertext as the engine of
> application state. But I don't understand your experiment yet. What do you
> mean by "simultaneously in modes a and b"? The experiment will fail for
> every system sooner or later, because the remote connection is unstable by
> definition.
>
> Best regards,
> Dietrich
>
> Via Boxer senden
>
> Am 21.04.2015 00:45 schrieb Martynas Jusevičius <martynas@graphity.org>:
> >
> > Hey everyone,
> >
> > I had this idea for a while of some kind of test for hypermedia agents.
> >
> > Consider 2 components:
> >
> > 1. a server S that serves data from a dataset D
> >
> > The server implements HATEOAS using vocabulary V to serve all possible
> > states for data output and input.
> > Vocabulary V defines the meaning of transitions between states.
> >
> > 2. client C that renders server responses as a user interface UI. The
> > UI renders all states and transitions served by S.
> >
> > The client has 2 modes:
> > - local, where it uses responses of an embedded server with dataset DL
> > - remote, where it uses responses of a remote server with dataset DR,
> > communicating over HTTP (the concept of a Linked Data browser)
> >
> > As a result, C can access its own dataset over HTTP by working
> > simultaneously in modes a and b.
> >
> > My "thesis" is: With the conditions that
> > - the only shared knowledge between S and C is V
> > - datasets DL and DR are equal
> > the S/C architecture is only really HATEOS if the UI is exactly the
> > same for every application state in local client mode and remote
> > client mode.
> >
> > Does this make any sense? :) It could most likely be simplified, but
> > probably becomes harder to demonstrate.
> >
> > This requires a client that can render and edit local and remote data
> > in exactly the same way. Formats such as JSON-LD as well as RDF/XML
> > should be useful for this.
> >
> >
> > Martynas
> >
>