Add relative path information to file objects

[Michalis]

Hi folks,

How about adding relative path information to file objects returned by the FileBrowse and DragAndDrop services?

This addition would give a big boost to applications that involve uploading files, since users will be able to select the top level folder of a complex structure and the application will be able to reconstruct that structure on the remote site.

For example, assume that we have the following structure on a Win-32 environment:

C:\....\MyPictures\
C:\....\MyPictures\image01.jpg
C:\....\MyPictures\image02.jpg
C:\....\MyPictures\Folder1
C:\....\MyPictures\Folder1\image11.jpg
C:\....\MyPictures\Folder1\image12.jpg
C:\....\MyPictures\Folder1\Folder2
C:\....\MyPictures\Folder1\Folder2\image21.jpg
C:\....\MyPictures\Folder1\Folder2\image22.jpg

Then the user selects (or drops) the "MyPictures" folder, the FileBrowse service should return the following array:

var files = [
{
BrowserPlusHandleId: 41,
BrowserPlusHandleName: "MyPictures",
BrowserPlusType: "BPTPath", // what does this stand for?
mimeType: ["application/x-folder"],
name: "MyPictures",
size: 0,
parent: null // null for top level directory
},
{
BrowserPlusHandleId: 42,
BrowserPlusHandleName: "image1.jpg",
BrowserPlusType: "BPTPath",
mimeType: ["image/jpeg", "image/pjpeg"],
name: "image1.jpg",
size: 0,
parent: files[0]
},
......
......
......
]

Alternatively to pointing to the parent object, one could represent hierarchy by unix-like path strings, eg "/" for the topo level folder, "/image1" etc.

I think that this modification will not break the BP security model principles, as it only exposes information relevant to items selected by the user.

Thanks

Michalis

PS Is there an estimation on the release of the source code of the FileBrowse and DragAndDrop services?

[Lloyd Hilaiel]

Hi folks,

How about adding relative path information to file objects returned by the FileBrowse and DragAndDrop services?

This addition would give a big boost to applications that involve uploading files, since users will be able to select the top level folder of a complex structure and the application will be able to reconstruct that structure on the remote site.

For example, assume that we have the following structure on a Win-32 environment:

C:\....\MyPictures\
C:\....\MyPictures\image01.jpg
C:\....\MyPictures\image02.jpg
C:\....\MyPictures\Folder1
C:\....\MyPictures\Folder1\image11.jpg
C:\....\MyPictures\Folder1\image12.jpg
C:\....\MyPictures\Folder1\Folder2
C:\....\MyPictures\Folder1\Folder2\image21.jpg
C:\....\MyPictures\Folder1\Folder2\image22.jpg

Then the user selects (or drops) the "MyPictures" folder, the FileBrowse service should return the following array:

var files = [
{
BrowserPlusHandleId: 41,
BrowserPlusHandleName: "MyPictures",
BrowserPlusType: "BPTPath", // what does this stand for?
mimeType: ["application/x-folder"],
name: "MyPictures",
size: 0,
parent: null // null for top level directory
},
{
BrowserPlusHandleId: 42,
BrowserPlusHandleName: "image1.jpg",
BrowserPlusType: "BPTPath",
mimeType: ["image/jpeg", "image/pjpeg"],
name: "image1.jpg",
size: 0,
parent: files[0]
},
......
......
......
]

Alternatively to pointing to the parent object, one could represent hierarchy by unix-like path strings, eg "/" for the topo level folder, "/image1" etc.

I think that this modification will not break the BP security model principles, as it only exposes information relevant to items selected by the user.

Thanks

Michalis

PS Is there an estimation on the release of the source code of the FileBrowse and DragAndDrop services?

Hey Michalis,

Thanks for sharing your thoughts. We actually spent some time talking about this idea today and all of us felt that it sounds reasonable. From a security standpoint It seems to jive with the other rules we've imposed. When you drop a file into a page you're allowing the page to interact with it... But, we've been holding off on changing the way selections are returned now because we have bigger plans. Here's the summary:

Today, both FileBrowse and DragAndDrop have very complicated return values. They both are capable of performing recursion, mime type filtering, and a host of other stuff. The problem is every time we add something in one place, it's got to be added in another. Furthermore, there are some types of services we would like to write that would return folders, and we'd have to replicate the features there too. So we hope to release 2.x versions of the FileBrowse and DragAndDrop services which return *exactly* what the user drops. No special manipulation. Then we would implement the various ways to recurse, extract nested files by mime type, or whatnot in a separate service. By moving this code into a distinct service it will be common between these two services, and perhaps useful in other ways in the future.

How's all that sound to you?

Now, as far as source code availablility, currently FileBrowse and DragAndDrop are part of the platform. The reason for this is because they must run *inside* the browser process in order to render modal windows or steal drops away from the browser. So the code for these services will be available when the platform code becomes available, and we're aiming to have that done before the end of the year.

The development of a Directory traversal service is under way now (by gordon), and I imagine he'll be dropping that service on github shortly. A lot of fun he's having with Windows "symlinks", shortcuts, ntfs "junctions", and a host of other stuff I've never heard of before!

very best,
lloyd

[Michalis]

Hey Michalis,

Thanks for sharing your thoughts. We actually spent some time talking about this idea today and all of us felt that it sounds reasonable. From a security standpoint It seems to jive with the other rules we've imposed. When you drop a file into a page you're allowing the page to interact with it... But, we've been holding off on changing the way selections are returned now because we have bigger plans. Here's the summary:

Today, both FileBrowse and DragAndDrop have very complicated return values. They both are capable of performing recursion, mime type filtering, and a host of other stuff. The problem is every time we add something in one place, it's got to be added in another. Furthermore, there are some types of services we would like to write that would return folders, and we'd have to replicate the features there too. So we hope to release 2.x versions of the FileBrowse and DragAndDrop services which return *exactly* what the user drops. No special manipulation. Then we would implement the various ways to recurse, extract nested files by mime type, or whatnot in a separate service. By moving this code into a distinct service it will be common between these two services, and perhaps useful in other ways in the future.

How's all that sound to you?

Now, as far as source code availablility, currently FileBrowse and DragAndDrop are part of the platform. The reason for this is because they must run *inside* the browser process in order to render modal windows or steal drops away from the browser. So the code for these services will be available when the platform code becomes available, and we're aiming to have that done before the end of the year.

The development of a Directory traversal service is under way now (by gordon), and I imagine he'll be dropping that service on github shortly. A lot of fun he's having with Windows "symlinks", shortcuts, ntfs "junctions", and a host of other stuff I've never heard of before!

very best,
lloyd

Hi Lloyd,

Thank you for your reply. What you describe sounds like the right thing to do, so we will be looking forward for the future releases of BP :-)

Best Regards,

Michalis