1

I have a dream of being able to work with applications on one computer, shutting down my current session, and being able to reopen that session on another computer. Primarily due to native resources specific to a certain machine, etc, it is not as far as I know possible to just serialize a process in .Net and move it to another machine. There's just too many reasons that wouldn't work. Probably the closest thing to this right now is a VM, but that's not what I'm looking for.

My specific question is this: Is there a framework built on .Net that helps enable this type of application? And if not in .Net, is there a framework not built on .Net that perhaps I could gain architectural insights from?

I imagine that such a framework would have to push access to native resources to the periphery of the application, abstract the common native resources (file I/O, graphics context), and build "hibernatable" subsystem building blocks to be able to start/stop the application. This probably would not leave much of the framework part of .Net still usable because it wouldn't use the abstractions, but I'm ok with that.

J Trana
  • 2,150
  • 2
  • 20
  • 32
  • Are you talking about creating an application that behaves in this way or creating an application that can make other applications (that you have not written) behave this way? – Albin Sunnanbo May 19 '12 at 06:08
  • @AlbinSunnanbo: I think the latter ... – IAbstract May 19 '12 at 06:13
  • To clarify, I understand this would probably take special support from both an application as well as some sort of controlling "server" application. I would not expect arbitrary programs to work, only programs using this framework. So I'm talking about both: a "server" app and framework that "client" applications (written by myself or others) could plug into to enable this functionality. – J Trana May 19 '12 at 06:24

1 Answers1

0

Well, I write almost that kind of applications all day long. Using the good ol' Server-Client pattern. The server keep track of all data and connecting clients fetches the latest data. This also solves the problem of having multiple users cooperating with the same data. The only missing part is to store the navigation state and currently "unsaved" data. That is simple to store on application exit, but that is usually irrelevant for the kind of applications that I write.

No special frameworks needed.

Albin Sunnanbo
  • 46,430
  • 8
  • 69
  • 108
  • True that. I've written one or two of that kind of app myself. :) But there tend to be a few thorny issues to solve: How thin is the client? If a long running task gets "paused"/hibernated, can it pick back up? Where's the data for that stored? etc. In the sort of setup I envision in my mind, this framework would essentially be the thickest client possible, with resources being essentially light servers as providers. In this way a lot of boilerplate is already written, and lines of work division are clear. In addition, I would like to be able to work completely offline once a session is moved. – J Trana May 19 '12 at 06:48