I completely agree with this. Would definitely be a breaking change, though, and require us to add the File plugin as a dependency. The file plugin dependency would be a good move too, I think, because then we might be able to strip out all of the content URI stuff we are doing in Android and have it in one place.
Thanks, Richard -----Original Message----- From: Sergey Grebnov (Akvelon) [mailto:v-seg...@microsoft.com] Sent: Thursday, November 12, 2015 9:47 PM To: dev@cordova.apache.org Subject: RE: Native vs. File URIs I would deprecate NATIVE_URI option due to the following reasons: * It confuses a lot, even us can hardly understand what the real difference (Native vs. File URIs) * I don't think it adds much value * It adds complexity as we should maintain/test NATIVE_URI support I think plugin consumers are really care where result is stored and returns - File vs base64 string. In case of File option we should return FileEntry and If someone need real path/etc he should just call FileEntry.toNativeUrl or something. My point is that ability to retrieve native path/url should be provided by FileEntry, not as Camera plugins separate option. Thx! Sergey -----Original Message----- From: Richard Knoll [mailto:rikn...@microsoft.com] Sent: Thursday, November 12, 2015 9:06 PM To: dev@cordova.apache.org Subject: RE: Native vs. File URIs Okay, so does that mean something like this: 1. FILE_URI always returns a file: // URI. If the URI we get from the image/document picker refers to something without a native path (e.g. in the cloud), we should probably copy it to a temp file on the device and return that URI 2. NATIVE_URI just returns whatever the native image/document picker or camera returned Do we need another option for cdvfile? Also, what core plugins actually use cdvfile? -----Original Message----- From: Shazron [mailto:shaz...@gmail.com] Sent: Monday, November 9, 2015 5:27 PM To: dev@cordova.apache.org Subject: Re: Native vs. File URIs For the Camera plugin, FILE_URI is a file:// URI and existed even before we created the file plugin's cdvfile:// cross-platform URI. We didn't change it for backwards compat reasons. On Mon, Nov 9, 2015 at 1:52 PM, Richard Knoll <rikn...@microsoft.com> wrote: > Does that mean that FILE_URI should exclusively be returning URIs that follow > the cdvfile:// scheme? Currently we never return those (at least, not in > Android). Is there anything else that can be defined as cross device? > > Thanks, > Richard > > -----Original Message----- > From: Jesse [mailto:purplecabb...@gmail.com] > Sent: Monday, November 9, 2015 11:45 AM > To: dev@cordova.apache.org > Subject: Re: Native vs. File URIs > > FILE_URI is cross device, NATIVE_URL is device specific, and intended to be > used when you need to know the REAL file path for something. > > > @purplecabbage > https://na01.safelinks.protection.outlook.com/?url=risingj.com&data=01 > %7c01%7cRIKNOLL%40exchange.microsoft.com%7ca343f6e3176f41d7d4a808d2e93 > e3956%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HJ0cDsXqCIWDzlpiv0D > pZLzHMKAWAHGsn7cL%2bamJpXg%3d > > On Mon, Nov 9, 2015 at 9:25 AM, Richard Knoll <rikn...@microsoft.com> wrote: > >> Oh, so does it refer to the location rather than the type of URI? >> That's fine with me, but if that is the case than we should still >> probably be sure that whatever is returned from the call is of a consistent >> type (i.e. >> always using content or always using file). >> >> Richard >> >> -----Original Message----- >> From: Shazron [mailto:shaz...@gmail.com] >> Sent: Friday, November 6, 2015 5:52 PM >> To: dev@cordova.apache.org >> Subject: Re: Native vs. File URIs >> >> I always thought a native URI was if the image was retrieved from the >> ALAssetsLibrary (Photos Album). >> >> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdeve >> l >> oper.apple.com%2flibrary%2fios%2fdocumentation%2fAssetsLibrary%2fRefe >> r >> ence%2fALAssetsLibrary_Class%2f&data=01%7c01%7cRIKNOLL%40exchange.mic >> r >> osoft.com%7c326ecc41750b4739501e08d2e7161af7%7c72f988bf86f141af91ab2d >> 7 >> cd011db47%7c1&sdata=k5JGWbePhlj4jmLCekW9tZiBlU11sE5cUv%2fr%2bqPMYkU%3 >> d and the file URI was the image we dumped into tmp. >> >> >> >> On Fri, Nov 6, 2015 at 11:43 AM, Richard Knoll >> <rikn...@microsoft.com> >> wrote: >> > Hey all, >> > >> > I was wondering if anybody could clarify for me what the difference >> between FILE_URI and NATIVE_URI is in the camera plugin. Do we have a >> clear definition of either? I assumed that FILE_URI would refer to an >> actual path on the device (i.e. a URI using the "file" scheme) but >> the docs for the camera plugin actually use a content URI as an example. >> This seems counterintuitive, especially since the "content" scheme is >> specific to Android. As it stands, FILE_URI and NATIVE_URI always >> return the same thing in Android and can either give a content URI or >> a file URI depending on the other camera options that are passed. I >> think we need to be clear when returning URIs so that app developers >> can tell what they have to do with it before they can use it in their >> app. Also, it's worth noting that the FILE_URI and NATIVE_URI >> question is complicated by the fact that on Android it is possible to >> pick photos using apps like Google Photos which can choose files that >> have no local path. I also would love some clarification as to where >> "cdvfile" fits into all of this and the type of support it has across the >> plugins. This is in regards to CB-9548, for those interested. >> > >> > Thanks, >> > Richard >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
