Re: Hydra Status

Hi all,

There's already quite a few strands on this email thread, but if we're
looking at overall direction there's another area I'd like to add -
real-time communication. This means communications over channels other than
HTTP.

An increasing amount work on the web is done with real time clients, e.g.
collaborative editing (Google Docs), messaging (Slack, Messenger) and
notification apps (calendars). This generally means using WebSockets as the
channel for communication.

With Hydra the focus so far has been on HTTP communication, e.g.
hydra:method. This is a request-reply pattern that doesn't work so well for
real-time. It would be great if a Hydra client could handle real-time
communications (sorry if I've missed any discussions covering this
already). Adding hypermedia to things like chat messages will be useful so
you know what actions you can take next (e.g. reply to chat message, delete
message, 'like' message, etc).

I've started thinking about this type of thing for the collaborative data
visualisation platform I'm working on, but haven't properly clarified
things yet. Hydra already describes the content of a message and what
operations you can do with it, that wont change. There might just be some
tinkering with bits like hydra:method and hydra:returns. Sending messages
shouldn't be a problem (we could expand hydra:method to request delivery
over a WebSocket), but deciding what the client is going to do with streams
of incoming messages might need a bit more thought.

At this stage just wanted to request that we put real-time communications
on the agenda as it's going to expand massively over the next couple of
years.

Cheers,

Kev

On 17 November 2016 at 09:45, Tomasz Pluskiewicz <tomasz@t-code.pl> wrote:

> November 16 2016 9:14 PM, "Markus Lanthaler" <markus.lanthaler@gmx.net>
> wrote:
> > On 15 Nov 2016 at 23:28, Graham Conzett wrote:
> >
> >> After this discussion I'm even less clear on who the intended audience
> >> is for Hydra is. Only people who are primarily focused on RDF?
> >
> > We want to build something which is usable by everyone.. also people
> without RDF background. But
> > people working on the design of Hydra itself need to be familiar with
> (or willing to learn the
> > basics of) RDF and other technologies Hydra is based on. Otherwise
> experience has shown that
> > constructive discussions are very difficult.
>
> I don't think it's the complete picture. IMO some of the discussions went
> into too much detail and tried to solve too distant problems. Not a problem
> with RDF itself, but maybe with the Semantic Web mindset. I know that we
> all would love to create a better Web but it has to come one step at a time.
>
> >
> > This doesn't mean people without background in those technologies and
> without time to learn them
> > can't participate. We will need input, use cases, feedback etc. People
> without RDF background are
> > crucial to ensure we built something approachable to everyone and
> eventually document it in an
> > accessible manner.
> >
>
> My point exactly. We need RDF knowledge to define Hydra and implement the
> tooling. But Hydra is for everyone. And the input of those not intimate
> with RDF is most valuable.
>
>
>


-- 
www.dataunity.org
twitter: @data_unity