Ray Ozzie: Introducing Live Mesh | Dan

staceyw
Before C# there was darkness...

jmazner wrote:

Bas wrote:
- What about email? Can I install Windows Live Mail on all my PC's and sync the message store across all PC's, so that I can check my email and read previously downloaded email on any PC? What will happen if I have my email client open on two PC's at the same time? Will it mess up the synch, or will I see emails appearing on my laptop when I download them on my desktop?

Email is one of those file types that's hard to synch today when you're dealing with a monolithic PST or OST file. Apps can certainly write to Live Mesh platform to enable great roaming of your email experience, but that will happen over time (once the platform is available.)

Actually, I was thinking a new email client "sample" would be a very interesting use case. If you started with the old school method of using files as messages instead of a single file DB, you could create a pretty nice email solution that syncs with all devices. Tasks could be 1 feed, email another, and calender another, etc. In fact, you could craft SqlServiceBroker or other queue on top of a feed to abstract the feeds from the app. Could also craft a CCR Port ontop of a feed.

And...If you used the feeds as a *transaction folder, the app could still use its' local DB, but just update itself using the "transactions" from the feeds. This would be just another level of indirection. That would be a fun and powerful solution to build.

You could also have private email Circles (spam free) with only members you allowed in the circle. And multiple Circles (i.e. work, friends, etc) Very interesting indeed...

Bas
It finds lightbulbs.

jmazner wrote:
Live Mesh also uses a control to display the RDP session in the browser. If someone has figured out how to parse and display RDP in JScript, I am all ears Not sure there's really any better solution here...

Well, there was that guy who wrote Lemmings in DHTML... Maybe you can learn from him. Tongue Out

No, but seriously, that's probably unavoidable, yeah. It's not a big deal, just something that hit me a couple of times with WHS, but there's probably no way around it.

jmazner wrote:

We don't have wake-on-LAN as part of our client communications platform. I will make sure that's on the list of things to consider.

That's the biggest omission from the WHS Console, IMHO. (And remote access website, by the way. I cannot stress the importance of being able to do it via a browser as well enough.)
It's easy to use an addon that allows for WOL functionality, but it's not exactly a smooth process in use. If the 'remotely connect to this PC' button (or whatever it is called) just automatically sent a WOL packet to the PC regardless of wether it supports WOL or not, you'd be there. It doesn't even have to be visible to the end user.

Thanks for considering it!

jmazner wrote:
Well, I don't think app settings are usually in My Documents?

Correct, my mistake. I meant the user's profile in \Documents and Settings or \Users, which has Local Settings and AppData folders. But I'm now thinking that it's probably a nightmare to sync that and not run into unpredictable problems on various devices, so scratch that.

jmazner wrote:

Email is one of those file types that's hard to synch today when you're dealing with a monolithic PST or OST file. Apps can certainly write to Live Mesh platform to enable great roaming of your email experience, but that will happen over time (once the platform is available.)

Interesting. But if I understand this correctly, Windows Live Mail, which, if I'm not mistaken, uses lots of small files for each email rather than one huge PST, would lend it self more easily to Meshing?

And let's hope that the Outlook team (and the entire Windows 7 Apps team, for that matter), is primed and ready to support this ASAP. Tongue Out

jmazner wrote:

Yes, using WHS as your own personal cloud storage is a popular request, and one that we are looking into. The platform is certainly designed to support multiple, federated storage servcies.

Excellent.

Thanks for the replies, Jeremy!

jmazner

Bas wrote:

jmazner wrote:
We don't have wake-on-LAN as part of our client communications platform. I will make sure that's on the list of things to consider.

That's the biggest omission from the WHS Console, IMHO. (And remote access website, by the way. I cannot stress the importance of being able to do it via a browser as well enough.)
It's easy to use an addon that allows for WOL functionality, but it's not exactly a smooth process in use. If the 'remotely connect to this PC' button (or whatever it is called) just automatically sent a WOL packet to the PC regardless of wether it supports WOL or not, you'd be there. It doesn't even have to be visible to the end user.

Thanks for considering it!

The suggestion is now officialy filed Smiley

This is not a trivial thing to get right, however. One of the keys to our software working behind NATs and firewalls is that our communications sessions are established by the client doing an HTTP GET to the server (to a special notification queue URL.) The server can then send any important information back to the client as a response to that GET. (the idea being it's much more reliable for the client to connect to the cloud than for the cloud to connect to the client)

When you click "Connect" to a remote device, that device sends an invite to the cloud, and then the cloud sends word of the invite through that notification queue.

If the remote client is asleep, it can't keep the HTTP connection open. So now the cloud has to figure out how to send a WOL packet to this machine that might be well hidden behind a NAT.

I'm not a networking guy by any means, so maybe there's a well established way to do this...but it sounds tricky to me, and in any event would be a different approach to remote connectivity than what we have built for the technology preview.

cheers,
j

Bas
It finds lightbulbs.

jmazner wrote:

The suggestion is now officialy filed

w00t! God bless Channel 9.

jmazner wrote:

This is not a trivial thing to get right, however.
j

Yeah, I should probably point out that I used the words "just automatically send a WOL packet" with blatant disregard for or knowledge about the intricacies of how everything actually works. Tongue Out

But even if there was some awareness to the fact that the device may not always be on and might be able to be woken up, that would be great. Currently the remote access features of WHS just assume that all your PC's are on, and pretend tat WOL doesn't exist. I'm not expecting you guys to be able to power up my Zune at home while I'm on the other side of the Atlantic, but even if WOL-features were limited to just the local network, that would be incredibly convenient.

Maybe it'd even be possible to send just an HTTP request to a machine that is online (like my WHS), and have that machine send the WOL packet to the sleeping device. That way the WOL-packet-sending-magic would only need to happen inside the LAN. But again, I have no idea how everything works, just what I want to see happen.

Anyway, thanks again!

staceyw
Before C# there was darkness...

Bas wrote:

jmazner wrote:
The suggestion is now officialy filed

w00t! God bless Channel 9.

jmazner wrote:
This is not a trivial thing to get right, however.
j

Yeah, I should probably point out that I used the words "just automatically send a WOL packet" with blatant disregard for or knowledge about the intricacies of how everything actually works.

But even if there was some awareness to the fact that the device may not always be on and might be able to be woken up, that would be great. Currently the remote access features of WHS just assume that all your PC's are on, and pretend tat WOL doesn't exist. I'm not expecting you guys to be able to power up my Zune at home while I'm on the other side of the Atlantic, but even if WOL-features were limited to just the local network, that would be incredibly convenient.

Maybe it'd even be possible to send just an HTTP request to a machine that is online (like my WHS), and have that machine send the WOL packet to the sleeping device. That way the WOL-packet-sending-magic would only need to happen inside the LAN. But again, I have no idea how everything works, just what I want to see happen.

Anyway, thanks again!

I am no WOL expert either. However, am a network guy. IMO, this should be handled completely by WOL and hw/driver pair sending wake up event to OS. So really, an app should not need any explicit knowledge of WOL packets, etc. If mesh client holds a socket open to server, WOL should wake up OS when any reply returns on socket. Some of the ack (and possibly other stuff) could be offloaded to the card to prevent some of the wake up ping-pong.

In general, however, power management and this kind of hosting support are at odds with each other and one needs to find their own balance based on needs. Needs of low power devices will most likely drive a good solution.