Subject: [core] mirroring as observe

From: [email-masked]
Date: Mon, 2 Apr 2012 12:21:06 +0200

Hi Carsten,

I'm reading your mirroring proposition with interest.
Your approach is close to the Publish option in the sense that you're 
mirroring on a per-resource basis.
But I like it better because the caching model is preserved and no new 
option is required.

This way I understand how Observe can work for sleepy devices because the 
creation of the observation relationship is actually controlled by the 
sleepy with a POST request.
I still don't understand Zach's point that the bare Observe option can 
work for sleepy devices, as is. For me the Observe relationship is just 
too fragile with a sleepy server. The client can only recreate the 
observation relationship at very specific and undefined points in time 
since the device is sleeping most of the time.

The mirror proxy draft is mirroring on a per-device basis. I'm very 
concerned with resource discovery of mirrored resources. IMO a separate 
explicit registration makes life easier for that. Also I think it is less 
efficient to mirror resources with static content (manufacturer, model) 
using observe because the sleepy needs to send notifications to each 
static resource just to keep the relationships alive. With a top entry for 
the registration, you can keep all mirrored sub-resources alive with a 
single update request.

By the way I need to find a new name for the mirror proxy because it's not 
a real proxy. Just a short poll. What folks think of
- Mirror server
- Mirroring Point
- Mail Box
- new idea?

When modelling mirroring as observe, the proxy and sleepy behave more like 
a typical proxy and server. Yet the proxy only supports GET requests 
through observe. So we're still working on a REST corner case where not 
all methods are applicable.

Matthieu