Suggested enhancement:- built-in Remote Desktop

[Aware]

So it seems that the strength of RedFly is as a dumb terminal. It does a fine job of extending the *interface* of mobile devices without adding any computing power. That same strength demands that there is no built-in DVD, or HDD or super-duper graphics chip etc.

I've read and I agree with the many reasons why RedFly has no memory, no software, minimal hardware etc., but it seems to me that if RedFly has it's own built-in Remote Desktop client that can simply utilise the network connection of the mobile device to connect to any net-connected device running whatever OS - Windows, Mac, Linux etc. - then RedFly becomes even more valuable.

Obviously most devices already support some sort of remote desktop, but I have a picture in my head that says if RedFly gets into bed with logMeIn or GoToMyPC there would be room for great synergy and greater support for the 'full' (whatever that means to you or to me) remote desktop experience.

 

[Ebag333]

If you have a built in Remote Desktop client then you're talking about needing a CPU, RAM, etc.....

*MUCH* more complex than a simple dumb terminal.

 

[Aware]

You dont need full OS etc if all you are doing is supporting the narrow confines of Remote Desktop.

Still a whole ton more complicated than building a web page or something, I know But not the same as requiring the whole shebang.

 

[wodin]

So how would RD be any better executed in the REDFLY hardware than it would be executed in the phone. The bottleneck is still going to be bandwidth.

 

[Ebag333]

You dont need full OS etc if all you are doing is supporting the narrow confines of Remote Desktop.

Still a whole ton more complicated than building a web page or something, I know But not the same as requiring the whole shebang.

No, but now you're talking about processing capability, video capability (not a simple driver either, but full blown video processing), network ability, memory management, etc.

So how would RD be any better executed in the REDFLY hardware than it would be executed in the phone. The bottleneck is still going to be bandwidth.

x2

You're going to be adding to the complexity (and price) of the Redfly, while adding very little benefit.



It's a cool idea, but not one that'd really see a lot of use I would think.

 

[Aware]

The single biggest negative I see in comments and reviews about the RedFly is - "is that all it does? I could get a [insert small-format, cheap laptop of choice here] for about the same money and it has full [blah blah list of limited computer features]".

Adding built-in RDP on a chip [it's easy to simplify when you don't have to actually solve the engineering problem ] would not answer all the nay-sayers, but it *would* add significant value whilst maintaining the dumb terminal, no storage goal of RedFly.

 

[Aware]

So how would RD be any better executed in the REDFLY hardware than it would be executed in the phone. The bottleneck is still going to be bandwidth.

Given the trouble I seem to be having getting RD to work with my Samsung BlackJack II, I think the quick answer is that it could add RDP capabilities to any device that has some sort of network connection, regardless of OS or features.

So you could, at least in theory, use s60, UIQ, Zune, iPhone, iPod Touch, a Linux phone, a GameBoy( ) or anything else that has networking capabilities and USB or Bluetooth. All Celio would need to develop is network-connectivity drivers for various devices. Still a big undertaking, but not so large as 'full' support for the tethered device, OS and software.

Did I say "at least in theory" yet?

 

[EdFrmBrighthand]

I'm torn.

On one level, I can see the advantage of this. It would give a default level of functionality to the Redfly.

On the other hand, it would require the device to be significantly more complicated. If nothing else, it would have to have some kind of networking ability beyond USB and Bluetooth. That's not a deal breaker, but it would distract Redfly developers away from the core functionality of the device. That's something I generally disapprove of.
-

 

[Ebag333]

I'm torn.

On one level, I can see the advantage of this. It would give a default level of functionality to the Redfly.

On the other hand, it would require the device to be significantly more complicated. If nothing else, it would have to have some kind of networking ability beyond USB and Bluetooth. That's not a deal breaker, but it would distract Redfly developers away from the core functionality of the device. That's something I generally disapprove of.
-

Exactly. You're going from a "dumb client" to a "thin client".

 

[Aware]

If nothing else, it would have to have some kind of networking ability beyond USB and Bluetooth. -

I did say it should use the networking feature of the device. I'm not claiming to have the knowledge to solve this, but it seems to me that it should be (in engineering terms) relatively easy to build a driver that connects to a device and can utilize its networking capabilities. This is less than what the current drivers must do to integrate with the device enough to work with all the installed software.

 

[Ebag333]

but it seems to me that it should be (in engineering terms) relatively easy to build a driver that connects to a device and can utilize its networking capabilities. This is less than what the current drivers must do to integrate with the device enough to work with all the installed software.

Actually this is exactly what the Redfly does currently.

What you're suggesting would be a thin client (essentially an operating system that performs a few simple functions) instead of a dumb client (a terminal with no operating system).

A thin client requires CPU, memory, video card, etc. Granted not nearly as much as a full blown computer/laptop, but still requires them. You might be talking about going from a 3 ghz processor to a 500 mhz one, but that's a huge change from no processor.

Many thin client devices run only web browsers or remote desktop software, meaning that all significant processing occurs on the server. However, recent devices marketed as thin clients can run complete operating systems such as Debian Linux, qualifying them as diskless nodes or hybrid clients. Some thin clients are also called "access terminals."

The thin client is a PC with less of everything.

http://en.wikipedia.org/wiki/Thin_client

The Redfly is not a PC, nor a laptop.

As I said, cool idea, completely different design.

 

[dc_in_sf]

My initial reaction to this idea was all negative, but I can see my merits if it made use of the phone for network connectivity.

My experience with RDP and the Redfly is that the processing power of the phone is somewhat of a bottleneck, this is easily observable by comparing the Redfly/Phone combo with a Laptop/Tethered Phone in the same location. Being able to offload the RDP client portion to the Redfly could conceivably improve the RDP experience (and bring it to life for smartphone users who are currently missing out).

That said, the major issue I see with this approach is that there are multiple RDP-style solutions (RDP, Citrix, VNC, LogMeIn etcetera) and supporting all of them natively would probably be a non starter. There may be software license fees for the non open source components as well that would drive up device cost.

So on balance, I'd rather see Celio improve core functionality (better video performance, support for more phones) then add a feature like this.

 

[ckj]

We at Celio realize (and have discussed at length over the last few months) the pros and cons pretty much exactly as you guys have described in this thread. Right now, we’re working on making the current REDFLY hardware better, less expensive, and more compatible, but possibly in the future, there are some attractive aspects to beefing up the hardware and embedding a remote access client (if there indeed is a large enough market for a product like that – which I personally believe there is). The end result would of course require additional components etc. to be added.

We have many, many thousands of man-hours (with patents to show from it) that have gone into optimizing software and hardware I/O from one device to another and a remote access piece of hardware could really, really, take advantage of our proprietary technology.