Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.mobile.android    |    Discussion about Android-based devices    |    236,147 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 235,692 of 236,147    |
|    Maria Sophia to Arno Welzel    |
|    Re: Discussion of FTP vs WebDav for Andr    |
|    29 Jan 26 11:34:09    |
      XPost: alt.comp.os.windows-11, alt.comp.os.windows-10       From: mariasophia@comprehension.com              Arno Welzel wrote:       >> You can't mount the Android filesystem as a Windows drive letter with FTP       >> (unless you add third-party software). But WebDAV needs no software.       >       > The issue with WebDAV in Windows is, that it does not work realiable.       >       >> Having the Android phone as a Windows drive has huge advantages, e.g., the       >> Windows file explorer can save DIRECTLY from Windows to Android in 1 step.       >       > Using the Windows file explorer you don't need a drive letter at all.       > That's the reason, why namespaces exist in the explorer - to be able to       > access locations even when they don't have a drive letter.       >       > A drive letter is only useful if you want to access the data in *other*       > applications besides the Windows file explorer which *require* a drive       > letter.              Hi Arno,              It is good that you are pointing out the differences between WebDAV and       FTP for connecting Windows to mobile devices. Those distinctions are real.              Regarding your comment that WebDAV in Windows is not reliable, I do not       doubt that it can fail. I am only saying that in my specific use model it       has been reliable enough to be useful. If you have concrete failure cases       it would help to list them, since the discussion here is about FTP vs       WebDAV. Without examples it is hard to understand what you mean by       unreliable in this context.              My setup is simple. I run a free WebDAV server on Android or iOS, then use       the built in Windows WebDAV client:              C:\> net use Z: \\192.168.1.2@8000\DavWWWRoot /USER:joe * /PERSISTENT:YES              No third party software on Windows, no shell extensions, no drivers.       Windows maps it as a normal filesystem. For my purposes this has been       stable, and the fact that it uses only built in components is a major       advantage. Scripts that expect a persistent drive letter work fine with       this mapping.              The biggest practical benefit for me is that I can save APK files directly       from a Windows browser session to the mobile device. APKs are useless on       Windows, so saving them straight to the phone is the natural workflow.       This is something FTP cannot do on Windows without third party redirectors,       because Windows has no FTP filesystem provider.              Only protocols with filesystem redirectors can be mapped as drives:       1. SMB has one.       2. WebDAV has one.       3. FTP does not.              That is a critical difference when the goal is full read write access to       the visible mobile filesystem through normal Windows applications.              You are correct that a drive letter is not required for basic file copying.       Explorer namespaces work fine for that, and adb does not need a drive       letter either. So yes, we can live without mapping the device.              But the question remains. How do you directly save an APK obtained during a       Windows web browsing session to the mobile device? That is the specific       workflow where a mapped drive letter matters, and where WebDAV provides       something that FTP cannot provide on Windows without extra software.              If we arbitrarily toss SMB into the mix, this is my assessment:        a. Can a web browser save an APK directly to Android with SMB?        b. Can a web browser save an APK directly to Android with WebDav?        c. Can a web browser save an APK directly to Android with FTP?              The answer, when we tackle iOS & SMB, is surprisingly unintuitive!              1. SMB       A Windows browser can save directly to an SMB share, but only if the       non-rooted/non-jailbroken mobile device is running an SMB server.              A. Android       Non-rooted Android cannot bind to privileged ports, which includes the       standard SMB ports. Because of that, Android SMB servers must run on       high ports. So SMB can work, but it is not useful on Android IMHO.              B. iOS       Shockingly, iOS is the only common consumer operating system that allows       apps to bind to privileged ports, so an SMB server on iOS can run on the       standard SMB ports and behave more like a normal SMB server.              In practice this makes SMB on iOS more useful than on Android.              In both cases, if the SMB server is reachable and writable, a Windows       browser can save directly to it because SMB is a real filesystem       provider in Windows.              2. WebDAV       A Windows browser can save directly to a mapped WebDAV drive letter.       WebDAV has a filesystem redirector in Windows, so the mobile device appears       as a normal drive. We can save an APK directly to Android during a Windows       web browsing session (without needing to save it and then copy it over).              3. FTP       Unfortunately a Windows browser cannot save directly to an FTP location.       Windows has no FTP filesystem provider, so FTP cannot be mapped, cannot be       assigned a drive letter, and cannot appear in Save dialogs. Explorer can       browse FTP, but only inside Explorer itself.              Having said those distinctions between SMB/WebDAV/FTP I certainly agree       with you that FTP/WebDAV are no longer being worked on my Microsoft.       --       Usenet is where people with vast knowledge converge to discuss ideas.              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca