Re: Mobile Lua - coming on strong

[Josh Simmons <simmons.44@...>]

On Tue, Nov 15, 2011 at 12:16 PM, David Given <dg@cowlark.com> wrote:
> On 15/11/11 00:29, Josh Simmons wrote:
> [...]
>> What are the advantages? More importantly, what are the use-cases?
>
> Hmm... how about a mail client? It's talking to a back-end server via
> IMAP, which is an interface that's effectively stateless (as the
> connection can be broken and recreated on demand). It stores a bunch of
> local state, including cached messages, user preferences, pending
> messages, and all the UI state.
>
> I'm running it on an Android device reading my mail on the bus. I start
> replying to an interesting message on Lua-L. My stop arrives. I chuck
> the device in the bag and go home. Once I get home, I get my device out,
> point it at my PC, and the mail client moves over to the desktop. I'm
> still looking at the Lua-L folder, the compose window is open with my
> text in it, and the cursor is exactly where I left it.
>
> Given the MVC triad, the M part lives on the cloud and the VC part is
> mobile.
>

I don't know about you but my mail client on my desktop is
considerably different in nearly every way to my mail client on my
phone. What you're proposing already works anyway by sharing data
without moving the entire application. This also has the advantage
that you're not tied to a particular vendor, open standards and all.
This also seems to require only a single running instance at any one
time, which is unrealistic if for example something prevents you from
moving the app.

> [...]
>> To me the issue with writing applications that run across multiple
>> machines is reliable concurrent access to shared data, not maintaining
>> a consistent internal program state.
>
> That's actually pretty easy. Most cloud RPC protocols these days are
> stateless, or nearly so, because it makes a huge number of problems go
> away. Traditional AJAX involves setting up and tearing down a TCP/IP
> session for every RPC request...
>

I wouldn't say easy, but that's my point if you have a stateless data
sharing system already what do you gain by getting clever and sharing
the application state too?

> I think the biggest problem, though, is that data fundamentally cannot
> be moved, only copied. But we really, really don't want two copies of
> your app running at once.

I disagree with this, we can see the success of inherently distributed
architectures in version control when we look at git, mercurial and
friends. Multiple copes are something that's going to happen anyway
given the non-perfect world in which these apps have to exist.