What are Mesh services?

Question

 Live Framework and Mesh Services: Live Services for Developers
 
Learn about the Live Framework including new and future services (such as Mesh Services), protocols, APIs, and tools which enable your Web, service, or client applications to access, store, and synchronize user data with Live Services, obtain audience analytics data, and more.
http://channel9.msdn.com/posts/Charles/New-sessions-announced-for-MIX09/

 
Care to share?

---

http://jamiethomson.spaces.live.com/ | http://blogs.conchango.com/jamiethomson

Answer 1

Jamie,
 
I would recommend you to watch PDC 2008 sessions as the technology was released there:

http://channel9.msdn.com/tags/pdc2008.live+framework/

Especially the following one if you want to learn more about Mesh Enabled Applications (MEWA):
http://channel9.msdn.com/pdc2008/BB30/


Hope this helps,

Rajan

---

(This post is provided "AS IS" with no warranties, and confers no rights.)

Answer 2

Rajan,
I know all about the Lie Framework, I've been using it since May. But the way that paragraph above was phrased it made it sound like Mesh Services was something else in addition to what's in live Framework. Am I wrong?

regards
Jamie

---

http://jamiethomson.spaces.live.com/ | http://blogs.conchango.com/jamiethomson

Answer 3

Oh, my bad. I misinterpreted your request differently. Let me read the para and research if we can offer details before MIX'2009. Just like PDC'2008, we may have tentative topics/description there. Mostly it's updated hours earlier before the event with final (release ready) information.

---

(This post is provided "AS IS" with no warranties, and confers no rights.)

Answer 4

Jamie,

I did some quick internal research. "Mesh services" is a term that we use commonly to refer mesh technologies that enables synchronizing user’s data and extending applications across multiple devices. They are one of the underlying core services of the Live Framework.

For example, you can consider the following services as core building block of mesh services:

• User services provide facilities for managing all aspects of a user’s Mesh (devices, applications, and data) and enabling sharing of those resources across multiple users.
• Device services provide facilities for managing the collection of heterogeneous devices within a user’s Mesh, including relationships, status, and security services.
• Application Management services facilitate the configuration; deployment and versioning of applications which utilize the Live Framework including Web-enabled Mesh Applications.
• Synchronization services as it ensures the synchronization of data and metadata between applications, devices, and the cloud.

 

So please bear with us if you see a new term related to Mesh, Live Services or LiveFx. Hence, functionally or technically - it's same stuff that you have been playing since post-PDC'2008.

Please let me know if you have any other questions.

Rajan

---

(This post is provided "AS IS" with no warranties, and confers no rights.)

Answer 5

Hmm... so if that's what Mesh Services are then what are Live Services, mentioned in the same paragraph?  Are they one and the same?

If Mesh Services are nothing new, then the only concrete scoop in the session abstract is the ability to obtain audience analytics data, which we knew was coming based on PDC details.  But I'm with Jamie, I still suspect Mesh Services may be something new and different from Live Services.

---

http://orand.blogspot.com

Answer 6

This will be a good topic for community discussion and branding thesis.

To quickly clarify, Mesh Services will go under umberalla of Live Services. Let me take a stab (being a technical guy) at this to explain this lil further.

I will say that "Live Services" are user-centric services that provide open, programmatic access to "Windows Live". These user-centric services include: Identity and authentication management, Presence Management (transient state of people and devices), Delivery engine for messages between clients and cloud. Also Device Management, Synchronization, App Management and Sharing - but these can be bundled under Mesh Services as another building block.

In nutshell, these services (Live and Mesh) provide the foundation for rich, structured user-centric data that is also exposed through open services.  Some examples of the data that is managed by Live Services include Profile, Contacts, Calendar, Photos, Blogs, and Mapping data.

LiveFx is a way to program Live Services as a building blocks for your application.

Hope it helps.

Cheers,

Rajan

---

(This post is provided "AS IS" with no warranties, and confers no rights.)

Answer 7

I think Live Services relate to all the services related to Windows Live - hotmail, contact, profile, maps, messenger, search, etc.

I think Mesh Services are the subset of Live Services related to the mesh.

Answer 8

Bingo!! You got it right.

---

(This post is provided "AS IS" with no warranties, and confers no rights.)

Answer 9

Oops, even though I have explained this same distinction to others in the past, I had forgotten. :-)

As a refresher, here's the official list of SDKs in the Live Services SDK.  One of those sub-SDKs is the Live Framework SDK.

The Live Services SDK isn't an SDK in the traditional sense.  It is more of a brand umbrella virtual SDK that is composed of individual SDKs.  You can't download an installer for "the Live Services SDK", you must download the sub-SDKs one at a time.

This branding hierarchy combined with all of the different types of Live Services tokens being issued in the past few months has resulted in significant confusion among developers, as evidenced by all of the "why doesn't my token work" threads in this forum, and the how do I download Live Services SDK thread.  When you take into consideration that the Live Services umbrella exists under the Azure Services Platform umbrella, even more confusion is guaranteed.

<rant withApologies="true">

I'm also annoyed that around the time of PDC someone decided to make a distinction between Live Mesh and Live Framework.  I don't like it, and I don't like its ripple effects such as renaming the Mesh Operating Environment (MOE) to the Live Operating Environment (LOE) and the Live Mesh Client to the Live Framework Client.  At least they haven't renamed Mesh-Enabled Web Apps (MEWA) to Live-Enabled Web Apps (LEWA) yet.  Shhh, don't tell them.

It's as if the executive responsible for the Live branding fiasco decided to lift his leg and leave his mark on one more product before the Kumo intervention makes Live a distant memory.  If this name-changing nonsense seems demoralizing to me, imagine what it must feel like to the folks working on the product.  This is a repeat of how it felt when we went from Indigo/Avalon to WCF/WPF.  There were plenty of folks inside and outside of Microsoft groaning about that one.  I remember Don Box cracking jokes at PDC05 about Windows Transaction Foundation.

I would argue that in less than a year, Live Mesh has gotten better brand recognition than Live Search, and I'll bet you that the word Mesh does the bulk of the work when it comes to recognition.  If you must make a distinction between the consumer experience and the developer experience, please don't drop the word Mesh.  Call it the Live Mesh Framework, or MeshFX, or something.

Back to the subject of the Live Services SDK, perhaps this pseudo-bundling strategy is Microsoft trying to use the Live Framework SDK as a Live gateway drug to persuade developers to take a closer look at the rest of the SDKs under the Live Services umbrella that haven't seen much adoption.  I'm guessing that most of these lesser SDKs will end up being accessible through Live Mesh at some point, but until that day, I think Live Services is wishful thinking that confuses the issue.

Another name that I take issue with is Live Framework Resource Scripts.  It appears that Resource Scripts is the Live-brand-neutered name for what was once known (perhaps informally) as MeshScripts.  I much prefer the name MeshScripts, for several reasons.  First, Microsoft already has an unrelated technology that uses the term Resource Scripts.  Second, you can't just use the generic-sounding term Resource Scripts and expect people to know what you're talking about.  You have to take a deep breath and say "Live Framework Resource Scripts."

</rant>

Anyway, I'm guessing it's too late to change the names now, but I just wanted to let it be known that the Live naming shenanigans haven't gone unnoticed, and in many cases we are continuing to pay for the confusion they have created.

---

http://orand.blogspot.com

Answer 10

 OK, thanks all. Imust be honest - its a strange thing to try and categorise. I look at Live framework as being access to the whole lot - I don't see a difference between the perceived mesh services and live services as they are explained here. Ah well, just me I guess.

---

http://jamiethomson.spaces.live.com/ | http://blogs.conchango.com/jamiethomson

Answer 11

I think of Live Framework as the resource-oriented programming model that will eventually provide a unified API on top of most of the various sub-SDKs in the Live Services SDK list.

This may be what those mysterious Federated Storage Services are that you mentioned in an earlier thread.

If you look at https://user-ctp.windows.net/ in the Resource Browser right now, you will see entries for /Mesh, /Profiles, and /Contacts.  These are exposed through the Live Framework .NET SDK as:

LiveOperatingEnvironment.Mesh

LiveOperatingEnvironment.Profiles

LiveOperatingEnvironment.Contacts

I think Profiles and Contacts may be examples of Federated Storage Services.  In the future, you might see /VirtualEarth, /Search, /Messaging, /Advertising, /Agents, /Spaces, etc. exposed from https://user-ctp.windows.net/.  These might be exposed in the .NET programming model as:

LiveOperatingEnvironment.Search

LiveOperatingEnvironment.Messaging

LiveOperatingEnvironment.Advertising

LiveOperatingEnvironment.Spaces

etc.

Dreaming big, there might even be an opportunity for third parties to add their own services to the root service document at https://user-ctp.windows.net/.

This is quite speculative and I could be completely wrong, but this is how I currently imagine the relationship between Live Framework (Mesh Services) and Live Services.

---

http://orand.blogspot.com

Answer 12

Oran,
Interesting thoughts. I certainly think that we will see a lot more going in there over time at the same level as Contacts, Profiles & Mesh.
I agree there'll be something in there to do with Search, Spaces would also make sense. As would groups given the existence now of http://groups.live.com. I'd expect our Hotmail inboxes to appear there as well.

I always understood FederatedStorageServices to be a way for 3rd party storage vendors (e.g. Box.net, JungleDisk) to tap into Mesh and be accessible via Mesh; I was quite surprised to see it go away actually.

I await with baited breath.

-Jamie

---

http://jamiethomson.spaces.live.com/ | http://blogs.conchango.com/jamiethomson

Answer 13

Ahh, that makes sense for third parties to live under /FederatedStorageServices rather than let them clutter up the root service document.  Groups and Hotmail would be interesting features.  Can't wait to see what's next!

---

http://orand.blogspot.com

Answer 14

Oran Dennison said:

...

I think Profiles and Contacts may be examples of Federated Storage Services.  In the future, you might see /VirtualEarth, /Search, /Messaging, /Advertising, /Agents, /Spaces, etc. exposed from https://user-ctp.windows.net/.  These might be exposed in the .NET programming model as:

LiveOperatingEnvironment.Search

LiveOperatingEnvironment.Messaging

LiveOperatingEnvironment.Advertising

LiveOperatingEnvironment.Spaces

etc.

Dreaming big, ...

---

http://orand.blogspot.com

Understanding that this conversation is totally speculative, the implication is that all of the content in these potential new services would be synchroniz*able* to a desktop, phone, car, refrigerator, sneaker or any device supported by the Mesh. 

A copy of your Digital Life would live in the cloud and parts of you would be synchronizable to local devices ...one a device by device basis.

Michael Herman
Parallelspace Corporation

Answer 15

Michael Herman - Parallelspace said:

Understanding that this conversation is totally speculative, the implication is that all of the content in these potential new services would be synchroniz*able* to a desktop, phone, car, refrigerator, sneaker or any device supported by the Mesh. 

A copy of your Digital Life would live in the cloud and parts of you would be synchronizable to local devices ...one a device by device basis.

Michael Herman
Parallelspace Corporation

Cool huh :)

Actually one that I forget. I'll bet that one of the things that you can store in your Mesh is your location. You could set it yourself or (here's the cool bit) delegate authority to a GPS unit to set it for you.
Another one that we've forgotten is Calendar. your Windows Llive calendars (http://calendar.live.com) will definitely be in there.


I can imagine it now....my (sync-equipped) Ford Focus says to me:
"Ah Mr Thomson, I see from your calendar that you have a meeting in Reading in an hour's time. It usually takes 45 minutes to get there from your current location but an accident on the M4 means that traffic is slow moving so you'd better get moving or else you'll be late. Here is the optimum route: http://maps.live.com/blah-blah-blah. Would you like me to plug the route into your GPS device for you?

Your friend Mr Smith has also been delayed by the traffic (his current location is shown on the previously linked to map) and is expected to arrive approximately 10 minutes late. I have informed all your colleagues that they may need to delay the meeting and have automatically re-booked the meeting room accordingly."

---

http://jamiethomson.spaces.live.com/ | http://blogs.conchango.com/jamiethomson

Answer 16

Whoa, can I get some Mesh-enabled Minority Report gloves too? ;-)

Good call on Calendar.  Check out this Channel9 video where Dharma Shukla describes the interfaces to Contacts and Profiles, and he also mentions Calendar like it's the next thing they're working on.  He says the interfaces to external systems are called service proxies, and it sounds like we may be able to write our own at some point.

You're right, GPS makes a ton of sense as well.  I would love to have Ori Amiga's MeshMobile, and not just because it's an awesome car in its own right...

Ahh, the possibilities!  The hardest part for the Mesh team must be prioritizing which cool thing to pursue next.

---

http://orand.blogspot.com

Answer 17

An important feature not mentioned so far is the centrality of feeds (and FeedSync) to the Mesh Services "resource-oriented programming model." If you are only looking for file storage or data storage and are not interested in feeds then you should probably look at Azure Storage or SDS rather than Mesh Services.

Answer 18

nmackenzie said:

An important feature not mentioned so far is the centrality of feeds (and FeedSync) to the Mesh Services "resource-oriented programming model." If you are only looking for file storage or data storage and are not interested in feeds then you should probably look at Azure Storage or SDS rather than Mesh Services.

Yup, I'm spending a lot of time looking at SDS right now though if all I wanted was pure blob storage I'd go for Azure for no other reason that I expect it to be cheaper.

---

http://jamiethomson.spaces.live.com/ | http://blogs.conchango.com/jamiethomson

Answer 19

There doesn't seem to be a big difference currently between Azure Storage and SDS but my understanding is that the data analysis capabilities of SDS will be boosted significantly. I believe the idea is that Azure Storage is designed for files while SDS is designed for data - and this was (is?) not apparent in the early documentation.

Answer 20

nmackenzie said:

There doesn't seem to be a big difference currently between Azure Storage and SDS but my understanding is that the data analysis capabilities of SDS will be boosted significantly. I believe the idea is that Azure Storage is designed for files while SDS is designed for data - and this was (is?) not apparent in the early documentation.

Yeah that's right - SDS is gonna get more feature-rich. I've blogged about this actually:

What’s the difference between SQL Data Services (SDS) and Azure tables?
(http://blogs.conchango.com/jamiethomson/archive/2008/12/12/what-s-the-difference-between-sql-data-services-sds-and-azure-tables.aspx)

---

http://jamiethomson.spaces.live.com/ | http://blogs.conchango.com/jamiethomson