I need to write a simple file transfer mechanism (that isn't ftp). Firstly, it must have a GUI. Secondly, it must not be dropbox. Third, it may not use any paid libraries, and hopefully, it uses open source components. The question that came to my mind is, where is everyone moving, from desktop to web, or from web to desktop? Would it be more useful to be experienced in say, C++ than in PHP (or vice versa)?
Asked
Active
Viewed 837 times
-2
-
2There is not common migration, and why not use a language that you can use for both. like say C# – Daniel Little Mar 18 '11 at 02:06
-
3If it's not FTP, and not Dropbox, and you have those restrictions...are you trying to reinvent some sort of wheel? – wkl Mar 18 '11 at 02:07
-
1Is this a homework assignment? If it's a genuine project: use FTP. – Carson63000 Mar 18 '11 at 04:41
3 Answers
1
IMO, "web vs. desktop" pretty much misses having any kind of point. There are clients and servers. While a desktop machine can be useful in a standalone situation, it's sufficiently rare anymore that it's hardly worth talking about. A server without clients is mostly pretty useless.
I don't see a lot really new or different happening on the server side right -- there's a lot of migration toward server virtualization, and I'd expect that to continue for the next few years or so. From a programming perspective, there's probably quite a bit of opportunity in doing a better job of managing virtual servers (especially large groups of them) but I don't expect a lot of changes in how the individual applications are written.
On the client side, the most obvious trend is away from being dominated by desktops toward mobile clients of various sorts. This does change the programming model somewhat -- particularly in having connectivity vary (widely) depending time and location. Most have some bandwidth essentially all the time, but when they're within range of a wi-fi hotspot, the bandwidth goes up a lot and the price drops to essentially zero. IMO, one of the outstanding challenges is providing data to the user over the low-bandwidth connection when needed, but trying to proactively use wider bandwidth when available in the hope of already having the necessary information when needed. Of course, the other interesting point is making optimal use of the (rather different) I/O capabilities available on mobile devices. Just for the obvious example, treating a touch-screen like a mouse does not work well.
Jerry Coffin
- 44,385
- 5
- 89
- 162
1
If you have any experience with .NET, you could always create a WCF (Windows Communication Foundation) application that can work on both an intranet and on the web. Here's a tutorial that looked like a decent starting point: http://stefanoricciardi.com/2009/08/28/file-transfer-with-wcp/.
I built a simple help request client using WCF, and while there is a somewhat steep learning curve (to understand what's going on, mostly), once you "get it," WCF makes this sort of thing child's play. It's not OpenSource, but you can use the Express Edition of Visual Web Developer (which is free) to build the WCF service and one of the other Express Editions to build the UI (or even Web Developer, if you go the web app route).
There is some support for WCF in Mono (check out http://www.mono-project.com/WCF), but I don't know if it's complete enough for what you're doing. If it is, you should be able to use MonoDevelop or SharpDevelop to program your app.
HTH.
Tieson T.
- 374
- 2
- 10
0
You should also add mobile to your list. Not only is the world moving away from the desktop and towards the flexibility and location-independent world of the Web, but it's also moving towards the Mobile Web.
jmort253
- 9,317
- 2
- 35
- 63