On 16 June 2012 04:06, Adam Howard <[email protected]> wrote:
> I'm including responses to both Mark and Dan here. I don't know if that
> meets
> list etiquette. Also should I be including full message history in every
> reply?
>
> So long as the message makes sense in its entirety, I don't think it
matters. I like to inline (as here) rather than top-reply or bottom-reply.
What I am going to do is to split out this thread into two; I'll reply to
your technical stuff on this one, and pick up Mark's reply to talk about
the legals.
>
>
> The cache that Johan is using seems a little different. When a domain
> object is
> returned from Isis, the graph is walked and more requests are made for
> properties, collections and descriptions. These all feed into a local
> representation of the state of the object. The window then displays the
> object
> as it exists in the cache. On subsequent requests for the object, it is
> ALWAYS
> refreshed from the server including all of its relations. So the cache is
> really
> just used to ensure that all current views are in sync with each other. So
> you
> change the name of a project and it's title is updated in the project list
> view
> because they are both pointing at the same javascript object.
>
>
in which case, sounds like a decent design. I'd keep with it.
>
> You mention the object's version. Is there an optimistic locking property
> exposed in RO? I searched the 1.0.0 spec and couldn't find one.
>
There is. I didn't use that phrase, instead search for "Concurrency
Control" - section 2.15 in the spec [1].
Basically, it's If-Match and ETag. I don't think that the json-viewer
supports this yet, but it will, of course, eventually.
>
> > This second point isn't an issue with an RO-based client, because
> > validation must trigger a call to the REST API... there is no Java code
> > client-side. Of course, with REST we can using HTTP caching to stop the
> > server being flooded with calls.
>
> The object traversal definitely floods the server. What would the
> cache-control
> be on an entity? Surely if we're asking we would want the latest version?
>
Section 2.13 talks a little about caching, and suggests that
implementations will return a cache value appropriate to the entity. For
example, some immutable reference entities (standing data, lookup values,
whatever you call it) could have a very long cache value. For
transactional entities, you are right that this would need a much shorter
cache. Even then, though, a cache value of 2 or 3 or 5 seconds is probably
sufficient... the spec says that implementations should make this tunable.
In the case of Isis, I was thinking that this would be done using facets
for the various annotations and possibly also imperative methods. For
example, probably an entity annotated with @Immutable would have a long
cache value (eg 86400 seconds = 1 day); other entities would be assumed as
transactional, and have a cache value of 3 seconds, tunable from
isis.properties config value. But a new annotation @CacheFor(5) might be
used as a hint to cache for 5 seconds; or there could be a method public
int cacheFor() { ... } that indicates how long to cache a particular
instance for. Lots of ideas.
> Related to the optimistic locking property above would we say "I want
> object
> OID:10. I currently have v123" and the server could determine that v123
> was the
> latest and send us a 304 (or do we keep track of when we requested the
> object
> and send that as If-modified-since?)
I think this is in the spec; see section 13, and section 13.10 in
particular.
Note that we use ETag primarily, because If-Modified-Since is only down to
the nearest second, I believe.
> Would it be different for value objects?
>
The REST API only returns bare value objects as a scalar action result
(section 12), eg an action OrderService#public int countPendingOrders() {
... }
The spec possibly isn't precise enough here, but at any rate... there
wouldn't be any ETag for these.
> And descriptions?
>
Not sure what you mean here, but if you are referring to the metadata
resources (section D of the spec), then - yes, these are immutable (and so
have a long cache expiry and no ETags).
>
> >> The next step I suppose would be to tie in either the WebSockets or
> >> EventSource API...
> >
>
> The two use cases I
> can see for this are streaming data and update announcements.
> Streaming data
> could be like a stock ticker or a continually updating chart. I've played
> with
> that before.
> The update announcements would broadcast that an object has changed
> server-side. It could include the full object or just the object id. The
> viewer
> could then choose to update the object in place or set a stale flag.
>
>
I think that the viewer would need to distinguish between these, probably
using metadata: (a) those entities where the view can be automatically
updated, ie are immutable to the user, and (b) those entities that can be
updated by users, and so we want to show that the user's current view is
stale.
For case (a), we could define a new @Streaming annotation for entities in
the Isis metamodel. The idea here might be that these entities are
immutable to the user, but can be streamed like a ticker. The viewer would
then subscribe to changes here through some new WebSocket API, and would
automatically update any views. (Perhaps the annotation might better be
called @Live, or @ServerUpdating, or ...?)
For case (b), again the viewer would subscribe to changes, but render any
such with a little marker button in the view. The idea is that it's a hint
to the user that what they are working on is out-of-date. They could click
the marker button and the viewer would attempt to merge in changes, or
(more simply) might just overwrite any changes client-side.
> It could be strange to see my Project view change in front of me
> (especially
> while I'm editing!) but there are cases where this could be very useful:
>
> * Shipping: Live map of where your package is.
> * The energy trading example from the first Naked Objects book.
> * Collaborative drawing: Not really a business system but often used to
> describe
> how rich we should strive to make our interfaces
>
> In the end, WebSockets is just a more server-friendly way to do what we
> have
> been doing with polling.
>
Lots of good ideas here...
The rest of your post was more on the "legals" sides, so I'll reply on the
other thread.
Cheers
Dan
[1] http://restfulobjects.org
