By Private Profile aad083ce on 2017-06-08 09:10 in GSoC 17 Media Manager

Venue : Glip

Time : 07/06/2017 UTC 17:30


List of Attendees Overview








Allon Moritz (Lead)



Kasun Vithanage



Yves Hoppe






David Neukirchen






Puneet Kala






Dimitris Grammatiko






Other Attendees:







General topics

Quick Intro

Currently Media Manager capable of displaying content from a single adapter, to do basic file operations like create, delete files and folders. To integrate cloud services with Joomla! Multiple Filesystems should be added to NMM.

This multiple adapter architecture directly involve with file operations across multiple file systems addressed in here.





The Schedule

The following table shows the schedule of the GsoC project. It was accepted by our GsoC Admin Yves Hoppe.




Time Allocation




Wed, June 7 – Thu, June 8

  • Discuss a Mechanism for handle multiple file systems in NMM

Short report about implementation

Fri, June 9 – Wed, June 21

  • Implementation

Implementation of mechanism


Thu, June 22 – Sat, June 24

  • Discuss a mechanism for serve files from cloud services

Short report about implementation

Sun, June 25 – Wed, July 5

  • Implementation

Implementation of mechanism


Thu, July 6 – Sat, July 8

  • Discuss about authorization for clouds

  • Decide which services are supported

Discussion report

Sun, July 9 – Wed, July 26

  • Implementation and test




Thu, July 27 – Sat, July 29

  • Discuss a mechanism for handle multiple cloud accounts from same service provider

Short report about implementation

Sun, July 30 – Mon, July 31

  • Implementation and test



MID SEMESTER EXAMINATION(Balance Period) [Tue, August 1 – Sun, August 13]



Mon, August 14 – Mon, August 28

  • Implementation and test





Blog Post

Blog posts from students about the work experience will be discussed here. Student will deliver a blog post about the project.



Implementation of multiple adapter support will be discussed here. Student has prepared a document with suggestions with their pros and cons.

Method 1

To get file list from Google Drive, following syntax can be used “gdrive:/”. As we want to add capability to handle multiple Google Drive Accounts we can extend this to “gdrive-0:/” so it will call to 1st google drive client registered with the system. So we can add this prefix to our path in XHR request and when it received to API Controller it will resolve for relevant media adapter and process the result.

It can even be possible to have the adapter name in the path as well like /gdrive/user1/images/holiday, where the first part is the adapter, then second the account and the rest the paths.



  • In the backend API it is easy to process the result with few lines of codes, for example to get the relevant adapter and the client, If “gdrive-2:/foo/bar/joomla.txt” is the path we can simply extract adapter by splitting by “:” and to get client we can simply again split by “-”.

  • Easy to handle copy/move between drives as we can send copy action with relevant drives in the url for example to copy foo/bar  from gdrive-1 to dropbox-9 we can simply send copy command with “?action=copy&src=gdrive-1:/foo/bar&dest=dropbox-9:/

  • Syntax is simple

  • Need only few modifications to existing api.json.php

  • Secure as tokens were not directly used in xhr request

  • Can be easily used to expose cloud media to articles



  • Will take some time to resolve for adapters

Method 2

Instead of adding adapter and client prefix directly to the the path we can add another input field to the XHR request like adapter=gdrive&client=1 and give the path relative to the file root of the adapter



  • Easier to extract details about adapters and clients.

  • Secure as no tokens were involved

  • Copy/Move could be implemented over multiple adapters



  • Copy/Move required to send both adapters and clients within request, so a separate procedure is needed to implement the task

  • Will take some time to resolve for adapters

Method 3

Instead of sending all the time the adapter names and clients, first when a relevant adapter selected in the list, we can set it as the current adapter in the backend. So each action would be executed using currentAdapter selected in the backend



  • Reduce network traffic

  • Faster than previous models as the adapter don’t need to be selected again and again

  • Secure



  • Implementing Copy/Move over multiple adapters is hard

  • State management in backend is involved

  • Drag  and Drop file operations will be hard to implement

  • To expose cloud media to articles etc need additional work to be done



It was decided to use the method 1 with 5 to 0 votes from the GsoC team. Implementation details will be discussed in the GsoC chat on a regular basis as there are some open points. The student will do a PoC first how multiadapter support will look like.