Live Framework CTP #5 – .NET: Data hierarchies and LiveItem types

Hierarchies of data entries – the problem

As stated before, when programming against the Live Framework libraries in .NET, all data entries are located on one level below the according data feed. This very often doesn’t correspond with a programmer’s expectations, when he has a hierarchy of data entries, e.g. a hierarchy of data folders and files. As programmer you want to have a tree-like view on this data to work with it. Unfortunately, in the current LiveFx CTP this was not made possible directly.

Extending DataFeed and DataEntry

The solution for this is not far away. A data entry’s resource has got an Id and a ParentId as properties, over which one can identify and associate an entry’s parent and its child entries. A „root entry“ has got the ParentId "urn:uuid:00000000-0000-0000-0000-000000000000" or it is null. This information is sufficient to write some extension methods on DataFeed and DataEntry for getting hierarchical information. Thus I’m starting to make a little class library, which I will further work on and extend it. First I’ve got a little class named „MeshConstants„. There resides the ParentId for a root data entry:

public static class MeshConstants
{
    public const string RootDataEntryId = "urn:uuid:00000000-0000-0000-0000-000000000000";
}

With this it’s easy to extend DataFeed with a method GetRootDataEntries(), which delivers only the data entries on the top level of the hierarchy:

public static ICollection<DataEntry> GetRootDataEntries(this DataFeed feed)
{
    return (from entry in feed.DataEntries.Entries
            where entry.IsLoaded && entry.IsRootEntry()
            select entry).ToList();
}

This method accesses IsRootEntry() of DataEntry, which is an extension method, too and indicates, if a data entry is on the root level (has no parent) or not:

public static bool IsRootEntry(this DataEntry entry)
{
    if (String.IsNullOrEmpty(entry.Resource.ParentId))
        return true;

    return entry.Resource.ParentId.Equals(MeshConstants.RootDataEntryId);
}

Another extension method for DataEntry gives us the child entries in return:

public static ICollection<DataEntry> GetChildEntries(this DataEntry entry)
{
    return (from child in entry.GetDataFeed().DataEntries.Entries
            where child.Resource.ParentId == entry.Resource.Id
            select child).ToList();
}

This makes use of the method GetDataFeed(), which is needed for getting the data feed, this data entry is associated to. Unfortunately, the .NET libraries of the Live Framework CTP don’t come along with this possibility innately:

public static DataFeed GetDataFeed(this DataEntry entry)
{
    return (from feed in
                (from meshobj in entry.LiveOperatingEnvironment.Mesh.MeshObjects.Entries
                 select meshobj.DataFeeds.Entries).Aggregate((fl1, fl2) => fl1.Union(fl2))
                 where feed.DataEntries.Entries.Contains(entry)
            select feed).Single();
}

Example: traversing the hierarchy

Now we’ve got all together for traversing a hierarchy of data entries recursively. We just need a recursive method, which executes the wanted action for a data entry and then recursively calls itself for all child entries. The following example method builds up a WinForms TreeView structure by adding TreeNode elements recursively:

private void addTreeNodesForChildDataEntries(DataEntry parentEntry, TreeNode parentNode)
{
    foreach (var childEntry in parentEntry.GetChildEntries())
    {
        var childNode = new TreeNode(childEntry.Resource.Title + ": " + childEntry.Resource.Type);
        parentNode.Nodes.Add(childNode);
        addTreeNodesForChildDataEntries(childEntry, childNode);
    }
}

The result is shown below exemplarily:

Live Framework - Recursing TreeView example

Types of LiveItem elements

The resources of MeshObject, DataFeed and DataEntry have an associated Type property, over which you can distinguish different types of objects. Furthermore, Type is a string and thus allows you to define your own application-specific object types. But the Live Framework comes with some standard types by default, where the most important are:

MeshObject.Type:

  • "LiveMeshFolder": Top-level folder, which can contain further (data entry) folders and files.
  • "ApplicationInstance": Instance of an application, which has been installed through the Live Application Catalogue.

DataFeed.Type:

  • "LiveMeshFiles": Indicates the feed as container for file and folder data entries.

DataEntry.Type:

  • "Folder": Data entry is a folder, which can contain further data entries.
  • "File": Data entry is a file, which may contain your data.

Based on that information (and the extension methods above), I’ve written some more extension methods on the several classes to filter the child elements accordingly:

public static class MeshObjectTypes
{
    public const string LiveMeshFolder = "LiveMeshFolder";
    public const string ApplicationInstance = "ApplicationInstance";
}

public static class DataFeedTypes
{
    public const string LiveMeshFiles = "LiveMeshFiles";
}

public static class DataEntryTypes
{
    public static string File = "File";
    public static string Folder = "Folder";
}

public static class MeshExtensions
{
    public static ICollection<MeshObject> GetApplicationInstanceMeshObjects(this Mesh mesh)
    {
        return (from meshobj in mesh.MeshObjects.Entries
                where meshobj.Resource.Type == MeshObjectTypes.ApplicationInstance
                select meshobj).ToList();
    }

    public static ICollection<MeshObject> GetFolderMeshObjects(this Mesh mesh)
    {
        return (from meshobj in mesh.MeshObjects.Entries
                where meshobj.Resource.Type == MeshObjectTypes.LiveMeshFolder
                select meshobj).ToList();
    }
}

public static class MeshObjectExtensions
{
    public static ICollection<DataFeed> GetFilesChildFeeds(this MeshObject meshobj)
    {
        return (from feed in meshobj.DataFeeds.Entries
                where feed.Resource.Type == DataFeedTypes.LiveMeshFiles
                select feed).ToList();
    }
}

public static class DataFeedExtensions
{
    public static ICollection<DataEntry> GetFileDataEntries(this DataFeed feed)
    {
        return feed.GetFileDataEntries(false);
    }

    public static ICollection<DataEntry> GetFolderDataEntries(this DataFeed feed)
    {
        return feed.GetFolderDataEntries(false);
    }

    public static ICollection<DataEntry> GetFileDataEntries(this DataFeed feed, bool onlyRootEntries)
    {
        var entries = onlyRootEntries ? feed.GetRootDataEntries() : feed.DataEntries.Entries;
        return (from entry in entries
                where entry.Resource.Type == DataEntryTypes.File
                select entry).ToList();
    }

    public static ICollection<DataEntry> GetFolderDataEntries(this DataFeed feed, bool onlyRootEntries)
    {
        var entries = onlyRootEntries ? feed.GetRootDataEntries() : feed.DataEntries.Entries;
        return (from entry in entries
                where entry.Resource.Type == DataEntryTypes.Folder
                select entry).ToList();
    }
}

public static class DataEntryExtensions
{
    public static ICollection<DataEntry> GetFileChildEntries(this DataEntry entry)
    {
        return (from child in entry.GetChildEntries()
                where child.Resource.Type == DataEntryTypes.File
                select child).ToList();
    }

    public static ICollection<DataEntry> GetFolderChildEntries(this DataEntry entry)
    {
        return (from child in entry.GetChildEntries()
                where child.Resource.Type == DataEntryTypes.Folder
                select child).ToList();
    }
}

kick it on DotNetKicks.com

Live Framework CTP #4 – .NET: LOE and data basics

Instead of creating new Silverlight applications, which run in your mesh and use the data, you can furthermore mesh-enable your existing .NET applications or create new mesh-enabled .NET applications from scratch. That’s pretty easy and in the following post I will show you some basics…

The Live Operating Environment (LOE)

First there is the Live Operating Environment, being the center point of all your operations to the mesh. With an object of type LiveOperatingEnvironment you can connect to your online mesh or to your local mesh storage sync or async and perform any operation you want. But that’s just the developer’s point of view. In fact, the LOE (every instance of it) is an agent component, responsible for providing an efficient cache and for background synchronization of data on your device to other devices (other instances of the LOE on those devices) in your mesh, including the „special“ LOE in the cloud. Running an LOE means exposing data through a RESTful interface at port 2048 of your machine – one could check the presence of this and either connect locally or to the cloud.

Connecting to your online/cloud LOE means that you have to provide your credentials on connect, whereas you can connect locally without those. I like to work on my local storage, it’s fast and safe. But there are some limitations (at the moment?) there. Due to the lack of file synchronization, files as data entries are not available from the local storage, so you have to connect to your online LOE instead. Furthermore you only get your local device in the Devices collection of your LOE and it’s not possible to have a look at your contacts and profiles for instance. What I expected first or want to have for the „final“ version of the Live Framework: just one connection method, which takes local data if it’s available and instead connects to the cloud LOE. It should be no problem, because the various LOEs (loal, cloud) are taking responsibility over synchronization… or have I forgotten to consider something?

Well, let’s take a look to connecting to your (online) LOE. Just create an instance of LiveOperatingEnvironment and connect via the Connect() method (local LOE: use ConnectLocally() instead). You have to pass your credentials as a parameter, which could come from a secure source or from user input:

var creds = new NetworkCredential("username", "password", "https://user-ctp.windows.net");
var loe = new LiveOperatingEnvironment();

loe.Connect(creds);

https://user-ctp.windows.net is the fixed base URI when connecting to your cloud LOE. After you’ve been connected, you get access to your mesh items (shown before) and can start meshing 🙂

Mesh Objects, Data Feeds and Data Entries

A mesh object is a container for concrete data in your mesh. There are several types of mesh objects and you are allowed to create your own application specific types, which your applications can work with. Mesh objects can be files, folders, applications, custom objects etc.. You have access to the mesh objects via loe.Mesh.MeshObjects.Entries and have the possibililty to easily iterate over them in this way.

Every mesh object consists of DataFeeds, Members, Mappings and News, as stated before. Interesting at this point are the data feeds. Those are further containers for the real data entries. Why this abstraction? Over data feeds you can group your data together, separating logically distinct data. Every DataFeed object finally contains a DataEntries collection, which gives you access to the underlying data and information about that. Note: there is no obvious possibility to store hierarchical data entries at the moment. There is one level of data entries and a data entry can’t contain other data entries. So that’s a drawback at this point and I don’t like/understand it much. The solution for that is: every data entry contains a parent ID and over that you can identify top level data entries and those, who are child entries of another data entry. But that’s not a good solution, isn’t it? Hopefully there will be done some work on that…

Well, a nice little .NET console application would be to show us the titles of all mesh objects, of their data feeds and data entries in there. That’s no problem and leads to the following little program:

var creds = new NetworkCredential("username", "password", "https://user-ctp.windows.net");
var loe = new LiveOperatingEnvironment();
loe.Connect(creds);
if (loe.IsRunning())
{
    foreach (var meshobj in loe.Mesh.MeshObjects.Entries)
    {
        Console.WriteLine("- " + meshobj.Resource.Title);
        foreach (var feed in meshobj.DataFeeds.Entries)
        {
            Console.WriteLine("  + " + feed.Resource.Title);
            foreach (var entry in feed.DataEntries.Entries)
                Console.WriteLine("    * " + entry.Resource.Title);
        }
    }
}
Console.ReadLine();

Create, Update, Delete

The creation, update and delete of all the three entities MeshObject, DataFeed and DataEntry is made really easy. Just call the Add() and Remove() methods of the particular collections. The rest is done automatically by the Live Framework. The update process isn’t problematic, too. Just change your entity and then make sure to call the Update() method of this entity. Because everything in your Live Operating Environment has LiveItem as base type, you have an integrated and consistent CRUD process.

Little example

The following screenshot shows a little WinForms application, that connects to my mesh and over which I can perform the CRUD process on my mesh entities. Further on I can navigate through my mesh and if I got images as data entries, those are downloaded automatically as media resource stream and then shown up at the picture box on the right. In the screen below is shown the (IKEA-powered 😉 ) couch corner of my little apartment…

Live Framework .NET WinForms example application

In upcoming blog posts I want to show you more information about handling data entries, media resources and hierarchical data. So stay tuned 🙂

kick it on DotNetKicks.com

Live Framework CTP #3 – .NET: the developer’s Resource Model

There seems to be a lack of information on the web about the Live Framework Resource Model from a developer’s point of view, that means how can I address my mesh objects and more from my .NET code. Some Blog-Entries describe it more from a user’s standpoint respectively describe what is unveiled through the web services of the Live Operating Environment, but as .NET developer with the LiveFx libraries at hand that’s not interesting me much. Thus I want to briefly describe the resource/data model which you’re programming against in .NET (it has some similarities to the real class diagram) through the following article. Later on, in other posts I will go in depth on some of them.

The following diagram shows many (while not all) aspects of what you as developer should be worried about when juggling with Live Framework objects:

Live Framework Resource Model

First things first: every collection shown above is a LiveItemCollection<TMeshItem, TResource>, where TMeshItem is of type MeshItem and TResource is of type Resource. Normally you get data out of the Resource, which can be extracted from the LiveItem via YourLiveItem.Resource.

Now I want to shortly describe the individual components.

LOE: the Live Operating Environment is the root of all functionality. Here you can connect to your Mesh and get all the information you need (In fact it’s much more than that, but this should be deferred at the moment).

  • Contacts: Collection, which holds your contacts. One contact can contain some profiles and has many relevant contact data (Name, adresses, job title, profession etc.) connected to it.
  • Mesh: Represents your whole mesh and the data, that it contains.
  • Profiles: Respresents your personal profiles. The following kinds of profiles are available: General, AboutYou, ContactInfo, WorkInfo, Interests. Those profiles come from your Windows Live account, so Windows Live is basically integrated with some functions at the moment. I’m sure that there will be more interaction and features including Mesh and Windows Live in the future.

Mesh:

  • Devices: Collection, that represents the different kinds of devices belonging to your mesh. Those are the same devices that are shown on the device ring in your browser. From a device object you can gather information like the online status, if it’s a local device or if it has an active remote connection.
  • MeshObjects: Everything, which can contain data (data feeds) in your mesh. This can be folders (Type: LiveMeshFolder) and applications (Type: ApplicationInstance) for example.
  • News: Collection of NewsItem objects, which represent global news in the mesh. There are several kinds of existing News types: LiveMesh.FileAdd, FolderAdd, MemberAdd, AppInstanceCreate, AppInstanceMemberAdd, UserMessagePost and more. But you’re not limited by these, because you can create news of your own type…

MeshObjects:

  • DataFeeds: Collection of container items for data, that is included in the mesh object. Every data feed can have many data entries.
  • Mappings: Collection, that contains mapping objects. Those indicate the devices this mesh object is mapped to.
  • Members: Individuals, who have permission to this mesh object. There are several role type for mesh object members: Full, Author, Reader, Writer. With those the core Live services and your applications can handle access to mesh objects.
  • News: Every mesh object can have several news, that are related to this object. As the global news, this is a LiveItemCollection of NewsItem objects.

DataFeeds:

  • DataEntries: Data entries are everything that contains data in a data feed. This can be files or folders or user-specific data. A data entry can contain a media resource, with which a file (image, video, audio, word document, …) can be viewed and converted automatically.

These are just some first thoughts and introductionary information about the resource model from a developer’s view. As said before, I will blog later on specific topics of that, going more in depth…

kick it on DotNetKicks.com

Live Framework CTP #2 – Silverlight: Hello Mesh

I recently created my first little mesh applications. And yeah, I like it! One of those was a simple „Hello Mesh“ Silverlight application, only to get familiar with the mesh application creation and deployment process.

Fist I created a new „Silverlight Mesh-enabled Web Application“, which can be chosen through the new „Live Framework“ project type, (comes with the Live Framework Tools for Visual Studio).

New Live Framework Project Type
New Live Framework Project Type
This results in the following project structure:
Silverlight Mesh-enabled Web Application project structure

There is a main application project „MeshApp1“, whose icon indicates that it’s mesh-enabled. Furthermore it contains a page that is hosting the Silverlight application „MeshApp1Silverlight“. I’ve heard that there are some problems, if you want to adopt this project structure to your custom needs. Some people seem to have problems when adding new references and projects, making the Silverlight application not work on a machine’s desktop. I’m sure that Microsoft is working on that, don’t forget we just have a CTP at the moment 😉

In Blend I’m layouting „Hello Mesh“ a little bit, so that my Mesh in the cloud is getting happy when it sees my application. Back in Visual Studio and ready to run, I make a thing which I call F5 deployment, regarding the effect of pressing the F5 key in my solution. So what’s going on? When you press F5 the first time, a dialog is popping up that is showing you some information about deploying your app:

Deployment dialog for a mesh-enabled web application

At present you have to make some handwork on this. With the Live Framework you can create up to 25 projects at the moment, this should be enough for some playground experiences. The dialog is showing you the way: you have to go to your Azure developer center and create a new project. In return you get an application self-link (the URI for the application), which the dialog wants from you. With this, Visual Studio knows where to deploy the application automatically, when you press F5 the next time. My opinion on this is that this kind of handwork could be made a little smarter or more automatic, but remember: you have to make it only once, so it is quite ok for me. 

What I think about this: that is how cloud application development and deployment should look like! Easy development with respect to your existing skills and easy deployment of your applications. Furthermore, with the application’s self-link, Visual Studio is able to debug your applications in the cloud. That’s great! No competitor of Microsoft gives you these possibilities and in my opinion it’s making a big difference and will contribute much to the success of Microsoft’s cloud strategy. Attracting developers is the core of all.

Aehrm, where have I been? Oh yeah… well… when you press F5, your Silverlight application will start in the cloud. The Live Desktop will open up and your Silverlight application will get a shortcut on it. It starts on your Live desktop, showing the overwhelming „Hello Mesh“ result:

Silverlight Mesh Application on the Live Desktop

If you run the „Live Framework Client“, this app automatically creates a shortcut on your machine’s desktop to the MeshApp1 Silverlight application. And in the background, it automatically synchronizes the application to your machine. Now try the following (it works!): disconnect from the Internet, click on the shortcut at your desktop and the application runs! Without connection, on your desktop. This really impresses me and I will try some more complex scenarios later on…  Here’s the local desktop result:

Silverlight Mesh-enabled Web Application on the local desktop

First conclusion: I like/love my first experiences with the Live Framework and that I can use my existing development skills. The deployment process is intuitive and easy and brings my expectations to life. I will go on with some more topics during the next days and weeks.

kick it on DotNetKicks.com

Live Framework CTP #1: Start!

The last two days I started playing around with the Live Framework CTP, where I was lucky to get a token from. I will write about my experiences in a series of postings in this place, so stay tuned. I encountered with some first issues and want to write about those in this posting.

Installation

After redeeming my Live Framework CTP token, I was able to download the following packages:

  • Live Framework Client: similary to the „normal user“ Live Mesh client, the Live Framework client runs in the background and allow synchronisation. In difference to the Live Mesh client it’s limited in functionality, as you will see later on. Note: the Live Framework Client is not needed for you as a developer to program against the Live Services, it’s just for background synchronisation.
  • Live Framework SDK: The Software Development Kit for the Live Framework. There is only a zip archive, no installation package. You have to copy the included folder into „C:/Program Files/Microsoft SDKs/“  by yourself. The SDK contains a resource browser tool, application samples, some documentation and libraries for .NET, Silverlight and Javascript.
  • Live Framework Tools for VS: This is an installation package which gives you a new project type „Live Framework“ when creating a project in Visual Studio, as shown below. There you can choose between „Mesh-enabled Web Application“ (allows you to create a Web App using the Live Framework Javascript library) and „Silverlight Mesh-enabled Web Application“, if you got the Silverlight Tools installed. Additionally it allows you to deploy your mesh application automatically in your mesh when running the app (I call it F5 deployment and like it very much – that’s how cloud should look from a developer’s point of view). Independently you can manually create mesh-enabled console/WPF/WinForms applications by adding the required libraries as references to your project. Thus you can easily add some mesh-functionality to your given applications.

That’s it. Installation worked fine except for the Live Framework Client (see below).

New Live Framework Project Type
New Live Framework Project Type

Developer Sandbox

With your Live Framework token you get a completely new Mesh in https://developer.mesh-ctp.com/. That means you can not use your existing „user“ Mesh from https://www.mesh.com/. You have to add devices again to your developer Mesh and it has the same 5GB storage (at the moment) and device ring/Live Desktop as your user mesh. In difference you can add applications to your developer mesh and this makes a big and even great difference.

Applications

At the moment there is no possibility to run applications in your user mesh. The developer mesh allows this. Some days before I shortly wrote (in German) about the Meshpack, which comes with 4 little Silverlight applications. The developer mesh allows you to include those 4 applications in your mesh with your Live Framework token at hand. The „Apps“ tab of your developer mesh will show those apps and allows you to create new instances of each one, which will appear on your Live Desktop and can be run from there. I’m waiting in suspense to see which applications will be available in the future through the public application catalogue, how they can be included in Windows Live and how you can share applications and there data with your friends!

The meshpack installed in the developer mesh
The meshpack installed in the developer mesh

Live Framework Client

The Live Framework and Live Mesh Clients

The „Live Framework Client“ is the developer mesh’s pendant to the „Live Mesh Client“ a normal user’s mesh comes with. The Client can be installed and then runs in the background. A taskbar icon will show you that you’re connected with your developer mesh and gives you recent news of your mesh.

There’s a really annoying issue with the Live Framework Client: if you have the Live Mesh client installed, you cannot install the Live Framework client! This frustrated me because I want to use the Live Framework, but at the same time I don’t want to miss the Live Mesh functionality on my machines.

Live Mesh and Live Framework client running side by sideBut I found a solution/workaround for this: you can uninstall the Live Mesh client and then you’re able to install the Live Framework client. After that install the Live Mesh client again and then you will not encounter any problems. I don’t know why Microsoft doesn’t allow both applications to run at the same time and I don’t know if there could be any problems with that. Until now I don’t have troubles with both applications and there synchronization functionalities.

In comparison to Live Mesh, the Live Framework client has some limitations in functionality. There is currently no ability to synchronize folders to your machine and you can’t connect remotely to other machines. Furthermore you can’t get online/offline information for your machines. At first look these are really annoying limitations, but at the second look it is no big problem for you as developer, who wants to explore the functionality of the Live Framework, not of the client.

The really great thing at the Live Framework Client is: you can synchronize applications between your mesh and your machines! From a developer’s point of view, applications in your mesh are just simple mesh objects, like mesh folders, mesh files and so on. This gives you a nice and consistent view of everything in your mesh. Applications can have data feeds, that means data which they contain. They have all the nice things other mesh objects have, too: news, members, feeds, mappings, …   and you can iterate through them programmatically, which will be shown in one of the next posts. So what means application synchronization? First when you include or deploy a Silverlight application into your mesh, you will automatically get a shortcut on your machine’s desktop! Thus you can start applications from your Live Desktop on the browser or directly from your desktop – it doesn’t matter. And with synchronization you’ll get all the data of the application (this means all data of the mesh object which is represented by your application). You can work offline with this data and if you come online again, this data will synchronize automatically with your mesh. Great stuff, isn’t it? I will give an in-depth look on that in a later blog entry…

When taking the meshpack as an example, there you’ve got the corkboard application. If you create a new instance of that in your mesh, you’ll get a shortcut on your Live Desktop and can start the app from there as shown below:

The corkboard application running on the Live desktop
The corkboard application running on the Live desktop

At the same time the Live Framework client notices the new application, synchronizes it with your machines and makes a shortcut on your desktop. From there you can start the application, which gives you nearly the same view as on your Live Desktop:

The corkboard application running locally on the user PC's desktop
The corkboard application running locally on the user PC's desktop

Live Mesh? Just an application!

When I first heard of and used the Live Mesh, I thought and spoke of Live Mesh all the time. But then I reconsidered the whole thing and found out the players behind the scenes. Is it Live Mesh we should speak about as developers? No, it’s not! Live Mesh is nothing but an application, a frontend of the real Mesh. In this mesh you have some nice things like devices, profiles, contacts, mesh objects (data, applications, …)  etc., which are populated via a restful web interface. Live Mesh uses this interface for displaying the device ring and Live desktop in your browser and for the features of the Live Mesh client (synchronization, …). The functionality of the Mesh itself is enabled by the Live Services as part of the service layer of Windows Azure. And with the Live Framework, you as developer are able to code against these Live Services and use all the functionality and data which are offered through Mesh and the Live Services. Thus you are able to create applications similar to Live Mesh or something really new. As your future killer apps, Live Mesh is only an end-user-friendly application build on the Live Services basement.

kick it on DotNetKicks.com

Guys, it’s Christmas (for me) – let’s start meshing!

Wow, that’s so really really great. I’ve written about my pains (German) while waiting for the Live Framework CTP Token before, but no the pains have ended! No, I did NOT get a token while poping out of the waiting list. I’m such a lucky man… Here’s the story: yesterday by „accident“ I was on a web page of a Live Framework blogger and by „accident“ I wrote her an e-mail, if she wouldn’t have a token for me. And in response:

You are lucky, my last token was requested through the blog but the person never responded back. [Here you have it]

Guys, I’m soooo happy! Finally I can now get experienced with the Live Framework, write my meshified applications and blog about it. What a beautiful day… it’s Christmas for me (only better ^^) 🙂

Bitte lasst meine Qualen enden!

Bitte Microsoft, habt Erbarmen mit uns! Bitte lasst die endlose Zeit der Warteliste vorübergehen und uns das Live Framework downloaden! Bitte lasst uns endlich gegen dieses Framework programmieren, lasst uns darüber bloggen, lasst uns darüber austauschen und unsere Kreativität darin ausleben. Bitte lasst die Qualen endlich enden.

Einen Monat warte ich nun schon auf einen Key für das Herunterladen des Live Frameworks, doch leider steht eine Freigabe noch immer aus. Und das bedeutet: anstatt weiter darüber zu bloggen, Tutorials zu schreiben und meine „Mesh-enabled applications“ damit zu entwickeln, drehe ich hier zu Hause Däumchen und hoffe auf ein vorzeitiges Weihnachtsgeschenk von Microsoft-Seite aus. Die Hoffnung stirbt zuletzt 😉

Dariusz Parys hatte heute für kurze Zeit 2 Keys für das Live Framework zu vergeben, die natürlich sofort weg waren. Das macht die Sache nur noch unerträglicher für mich, wann hat das Warten endlich ein Ende? Was mich zur nächsten Frage führt, warum überhaupt eine Warteliste existiert. Meine Vermutung sind derzeit mangelnde Ressourcen im Backend, die ansonsten vielleicht nicht ausreichen würden, wenn Tausende von Entwicklern ihre Programme auf ihren Meshs laufen lassen. Andere Ideen?

Vorhang auf für… das MeshPack

Wie bereits zuvor beschrieben, ist Live Mesh nicht lediglich ein weiteres Synchronisationstool, sondern unter der Oberfläche eine Plattform für die Bereitstellung umfangreicher verteilter Funktionen, gegen die mit dem Live Framework programmiert werden kann. Und wie vermutet haben die Microsoft Startup Labs nun (Blog-Eintrag) als „Showcase“ die ersten 4 Mesh-Applikationen veröffentlicht: das MeshPack! (Zugang mit PDC-Code)

Die 4 Anwendungen lauten wie folgt:

  • Collaborative Crossword: Ein Kreuzworträtsel, welches von mehreren Benutzern zusammen (kollaborativ) gelöst werden kann.
  • CorkBoard: Digitales schwarzes Brett.
  • CrowdVote: Kollaboratives Umfragen-/Abstimmungstool.
  • MeshLists: Tool zur Erzeugung und zum Austausch von Listen.

Die Anwendungen basieren grundlegend auf den zur Verfügung gestellten Mesh-Objekten, z.B. den Feeds, um Informationen auszutauschen. Bei der Realisierung des Kreuzworträtsels kommt zudem Silverlight zum Einsatz, um die Mesh-Funktionalität mit einer RIA-Oberfläche zu verbinden.

Sicherlich ist keine dieser Anwendungen eine Killer-App und anscheinend spielen die Jungs bei Microsoft selbst noch mit dem Framework rum und erforschen, welche Ideen möglich bzw. sinnvoll sind. Persönlich vermute ich, dass im Hintergrund bereits größere Projekte angesetzt sind und umgesetzt werden, diese jedoch noch keinen Status erreicht haben, der es wert wäre, die Anwendungen das Licht der Welt erblicken zu lassen. Ich bin sehr gespannt, wie es hier weitergeht.

Links:

Mesh me up!

Microsoft’s Live Mesh ist ja nun endlich auch offiziell als Betaversion in Deutschland verfügbar. Grund genug, sich diese Web-Applikation einmal genauer anzuschauen…  Live Mesh (bzw. das derzeitige Frontend) ist (momentan!) vordergründig ein Online-Dienst zur Synchronisation von Daten zwischen mehreren Rechnern. Gerade für mich, der 3 Rechner besitzt und diese auch abwechselnd in Betrieb hat, kommt so eine Lösung gerade recht. Daten (z.B. Visual-Studio-Projekte), welche man auf allen seinen Rechnern immer auf dem aktuellsten Stand haben möchte, ohne z.B. über einen LAN-Server darauf zuzugreifen, können auf diese Art schnell synchronisiert werden.

Live Mesh

Mit seiner Windows-Live-ID hat man sich schnell beim Mesh-Dienst angemeldet und kann ein/sein Mesh anlegen. Zum Mesh gehört grundsätzlich eine Weboberfläche, über die neue Ordner angelegt werden können und über die sich neue Rechner/Geräte leicht in das bestehende Mesh aufnehmen lassen. Zudem steht über den „Live Desktop“ eine Art Desktop im Browser zur Verfügung, über den sich Dateien öffnen lassen und sogar Bilder angeschaut und Video-/Audio-Dateien abgespielt werden können. Die Datenhaltung erfolgt zentral, d.h. die zu synchronisierenden Daten liegen auf einem Server in einem MS-Datencenter, wobei der eigene Account über 5GB kostenlosen Speicher verfügt. Sensible Daten sollte man hier vielleicht nicht ablegen, je nachdem wie sehr man Microsoft vertraut 🙂  Dies ist sicher auch der größte Knackpunkt der Applikation, da nicht jeder Benutzer seine Daten auf einem Microsoft-Server halten möchte…

Clientseitig wird auf jedem Rechner, der an der Datensynchronisation teilhaben soll, eine kleine Desktop-Applikation installiert. Nachdem man den Rechner über die Webplattform zum Mesh hinzugefügt hat, lassen sich über diese Applikation schnell zu synchronisierende Ordner auswählen. Insgesamt erhält also jeder Client eine lokale Kopie der Ordner, die im Mesh abgelegt sind. Auf dieser Kopie kann gearbeitet werden und Dateien können geändert werden. Die Clientapplikation sorgt dann automatisch dafür, dass Änderungen zum zentralen Server hochgeladen werden und dann an die anderen angeschlossenen Geräte verteilt werden. So wird dafür gesorgt, dass die Dateien ohne Zutun des Benutzers auf dem aktuellen Stand sind. Benutzerfreundlicher kann man es kaum gestalten. Derzeit lassen sich Windows- und Mac-Rechner zum Mesh hinzufügen, bald sollen auch Mobiltelefone integriert werden können.

Nur zur Synchronisation?

Synchronisationssoftwares gibt es viele, Live Mesh bietet aber noch ein bisschen mehr. Über den Live Desktop kann man auch von Rechnern, die nicht an der Synchronisation teilhaben, auf Dateien zugreifen und neue Dateien hinzufügen. Die Webapplikation ist komplett in Silverlight geschrieben und gestaltet sich entsprechend intuitiv und benutzerfreundlich. Weiterhin kann man andere einladen und ihnen Zugriff auf einen Ordner gewähren. Somit lassen sich bestimmte Ordner leicht austauschen und gleichzeitig synchron halten. Eine News-Seite informiert dabei über aktuelle Änderungen und erlaubt auch ein Hinterlassen eigener Nachrichten. Eine interessante Möglichkeit ist zudem die Option, einen Remote-Zugriff via Live Mesh zu gewähren. Rechner, die online sind, können so von einem selbst über Live Mesh ferngesteuert werden, wenn man dies erlauben möchte.

Zukunftsstrategie

Microsoft hat ja bereits mit Groove eine Synchronisationssoftware im Programm, was macht Mesh also für einen Sinn bzw. besonders? Insgesamt kann man Live Mesh bzw. das, was derzeit davon zu sehen ist, guten Gewissens als Spitze eines riesigen Eisberges sehen. Ziel ist vielmehr die Vereinigung der 4 Elemente Applikationen, Geräte, Daten und Menschen. Den Zugriff und Austausch zwischen diesen Elementen zu vereinheitlichen ist das Ziel von Live Mesh. Unter der Oberfläche ist die Windows Azure Plattform angesiedelt, darauf setzen die sogenannten „Live Services“ auf (s. Bild unten). Diese stellen Dienste/Services für Live Mesh zur Verfügung und über das Live Framework kann bequem dagegen programmiert werden. Das alles sieht sehr elegant und einfach aus. Um z.B. alle zum Mesh gehörenden Devices abzurufen, genügen folgende Zeilen: „var livefx = new LiveOperatingEnvironment(); livefx.Connect(); foreach(var dev in livefx.Mesh.Devices) …“. Außer Devices gibt es noch allgemeine Mesh Objects, Data Feeds und Data Entries, Contacts, Profiles, News, Media Resources etc.. Das Live Framework ist als CTP bereits verfügbar, allerdings existiert für den Download eine Warteliste, die ziemlich lang sein dürfte (ich warte immernoch…). Microsoft hat weiterhin bereits damit begonnen, auf Basis des Live Frameworks einige Applikationen zu schreiben. Im Vorfeld wurde schonmal mit Tracker eine „Demo-App“ zur Aufgabenverwaltung vorgestellt. Man stelle sich aber vor, was mit dieser Technologie alles möglich ist! Eigene Applikationen können leicht alle Mesh-Features nutzen und Daten über das Mesh anderen Devices zur Verfügung stellen. Weiterhin sind Anwendungen denkbar, die sowohl auf dem Live Desktop als auch auf den Client-Rechnern laufen und somit von überall erreichbar sind.

Ich bin gespannt, was da demnächst auf uns zukommt – get meshified 🙂