Project

General

Profile

GSoC 2013 "Cloud Ready" Project Specification » History » Version 6

Robin Mills, 27 Feb 2013 23:14

1 1 Robin Mills
h1. GSoC 2013 "Cloud Ready" Project Specification
2
3 2 Robin Mills
There are four subprojects:
4
5 3 Robin Mills
# HTTP I/O support (GSoC 2013 Student)
6 2 Robin Mills
# exiv2(.exe) to run as a service (daemon) on a web socket.
7
# client-side use of the exiv2 service (using the web socket)
8
# JSON support 
9
10 4 Robin Mills
This is quite a large project.  Robin Mills intends to implement the daemon/web-socket support during Spring 2013.  The GSoC student is expected to implement the http I/O support.  The proposal to have a GSoC student join us will be made via KDE http://community.kde.org/GSoC/2013/Ideas#Exiv2_.22Cloud_Ready.22_Project
11 1 Robin Mills
12 3 Robin Mills
h2. 1 HTTP I/O support (GSoC 2013 Student)
13 1 Robin Mills
14 3 Robin Mills
Today we provide support files available on the file system. These files can be memory mapped if this feature is supported by the host OS.
15
16
With the increasing interest in "cloud" computing, it's become ever more common for files to reside in remote locations which are not mapped to the file system. Very common cases today are ftp and http. For example: http://bla/bla/bla/file.jpg. Today there are a myriad of "Cloud" storage products, such as AWS, DropBox, Google Drive, Sky Drive, Box,iCloud, Just Cloud and more.
17
18
The proposal is to support http, ftp and ssh. This can be done by deriving a new Class from the BasicIO abstract class. The exiv2 command would accept filenames with a URL. For example:
19
20
<pre>
21
exiv2 -pt http://clanmills.com/files/Robin.jpg
22
exiv2 -pt ftp://username@password:/clanmills.com/Robin.jpg
23
exiv2 -pt ssh://username@password:/clanmills.com/Robin.jpg
24
</pre>
25
In most image files, the meta-data is defined in the first 100k of the file, so the implementation should only read blocks on demand from the server and avoid copying the complete file.
26
27
The simplest possible implementation of this proposal for exiv2 to detect the protocol and use a helper application such as curl or ssh. This implementation probably requires copying the complete file from the remote storage to a temporary file in the local file system. While such an implementation can be constructed quickly, this does not satisfy the project aim to make efficient use of band-width.
28
29
It is very desirable to use a robust implementation of the web protocols and a library such as libcurl should be considered. The selection of the protocol support library must respect build implications. We should be careful to avoid adding a large library (such as boost) to the build dependencies. Additionally, the implementation is required to be written in C++ and run on Mac/Windows/Linux without dependency on platform frameworks such as .Net, Java, or Cocoa. It may be that build switches can be provided to enable Exiv2 to use platform frameworks. This could be especially useful on mobile platforms such as Android and iOS.
30
31
The implementation should provide bi-directional support (both read and write) with read-access being the first priority.
32
33
h2. 2 and 3 Exiv2 daemon server and client
34
35
enable exiv2 to run as a service (daemon) on a web socket. I imagine two types of clients:
36
37
# exiv2 itself of course
38
# JavaScript/WebSocket client
39
40
To do this we could do something like this:
41
<pre>
42
Server:      # exiv2 --daemon --port 54321
43
Client:      $ exiv2 -pt exv://server:54321:/Robin.jpg
44
Even better: $ exiv2 -pt exv://server:54321:/http://clanmills.com/files/Robin.jpg
45
</pre>I don't want to get into detail concerning the JavaScript API for this. Something like this:
46
<pre>
47
<script src="js/Exiv2.js">
48
var exiv2     = new Exiv2( { server : 'clanmills.com' , port : 54321 }); 
49
var metadata  = eval(exiv2.command('--JSON -pt /Robin.jpg '));
50
// or even better
51
var metadata  = eval(exiv2.command('--JSON -pt http://clanmills.com/files/Robin.jpg'));
52
</pre>To get the most from this functionality, we should provide JSON (and/or XML) support which I discuss below.
53
54
h2. 4 JSON Support
55
56
5 years ago, I became interested in exiv2 to implement a GeoTagging application. I decided to use Python as an excuse to learn the language. I used the pyexiv2 wrapper, written by Olivier, and the project was a success. Building exiv2 and pyexiv2 on Windows and MacOSX was a challenge (to say the least).
57
58
Since then, I've worked steadily on the exiv2 msvc and msvc64 built environments and I believe both are working very well.
59
60
Sadly, building pyexiv2 is remains a challenge because it requires boost and the scons build utility. (scons is/was another GSoC project.) The consequence is that my python script seldom uses the latest exiv2 and is not available on all my machines (Windows/Cygwin/Mac/Kubuntu). The script is stable (hardly been changed in 5 years), however building the pyexiv2 wrapper is a maintenance challenge. The pyexiv2 has to be built for specific versions of python (2.6, 2.7 etc), architecture (32/64 bit), platform (windows/cygwin/macosx/linux).
61
62
This is not a criticism of Olivier's pyexiv2 wrapper. Olivier has done a very good job. Python wrappers which link C++ are a severe maintenance challenge. I haven't worked for years with Perl's C++ support (XS and/or SWIG), however I anticipate similar pain and trouble.
63
64
JSON to the rescue. My proposal is to provide a JSON interface to read and write meta-data in the exiv2 command-line utility.
65
66
As an sample application to prove our JSON support, provide wrappers for Perl and Python. The wrappers can be written entirely in the scripting language and use the language's JSON support. There is no need to get involved with C++ integration challenges such as boost/scons/pyexiv2, xs and swig. When reading from files, the wrapper will call exiv2.exe ONCE to capture all JSON to file. When writing to files, the wrapper will call exiv2.exe ONCE. This strategy will enable the wrappers to and run on all platforms on which exiv2.exe is available.
67
68
h2. Expected results:
69
70
# To deploy a webservice to provide Exiv2 services.
71
# To provide a JavaScript library to enable developers use the Exiv2 service.
72
# An engineering assessment of the effort involved in providing access to cloud servers such as AWS.
73
74
h2. GSoC Mentor:
75
76 2 Robin Mills
Robin Mills http://clanmills.com/files/CV.pdf
77
78
I've been a volunteer on the Exiv2 project for 5 years.  I worked for Adobe for 10 years, where I implemented reading PDF and JDF files over http (without copying the complete file).  I'm now a freelance contractor and I've been working on a mobile app which uses WebSockets.  I've worked on both server and client code.
79 5 Robin Mills
80
h2. Project Notes:
81
82
If you wish the submit a proposal, or discuss this project with me, then please do the following:
83
84
* Confirm with me that you have good C++ skills
85
* Download and build Exiv2.
86
87
When you read the code, here are some suggestions for matters you may wish to consider:
88
89
h3. 1)	Exiv2 BasicIO abstract class and HttpIO concrete class (for reading)
90
91
*	I don’t remember the API, however it has methods to read from stream (open/close/tell/seek,read,write)
92
*	You should derive a new class from BasicIO, and could be called HttpIO or something like that
93
*	HttpIO should allocate memory for the complete file and maintain a map of blocks which have been copied from the server
94
*	When a read is requested, HttpIO should ensure the appropriate blocks have been requested, update the map, return data
95
*	The copy from the server should use HTTP’s ‘byte range’ to limit limit the number of bytes to be copied
96
97
h3. 2)	HttpIO and writing
98
99
*	I’ve never wanted to write "byte-ranges" over http.  We need to research this.
100
*	However the map should maintain the parts of the file which have changed and only send those blocks to the server.
101
102
h3. 3)	Protocol support library
103
104
*	I respect libcurl.  I believe it supports http/https/ftp/sftp
105
*	I’m sure it can do ‘byte-ranges” for http/gets. 
106
*	I don’t know if it can do byte-ranges on other protocols
107
108
h3. 4)	Other protocols
109
110
*	Other protocols may be possible. (smb, nfs, ssh).  Needs to be investigated.
111
*	Cloud protocols (AWS, DropBox etc).  Needs to be investigated.
112
113
h3. 5)  User Interface, test harness and Platforms
114
115 6 Robin Mills
Exiv2 is a library.  There is no user interface.  Exiv2 includes about 20 sample applications which are all command-line programs.  The main application is exiv2(.exe) which does many things and is used by the test suite.  The test suite is written in bash.  On Windows, the test suite is run from Cygwin - however it can test libraries built with Visual Studio as well as GCC and Clang.
116 5 Robin Mills
117 6 Robin Mills
All code is required to build, execute and test correctly on the major platforms: Windows/MacOSX/Linux.  I will provide help to port from the development system to the others.
118 5 Robin Mills
119
h3. 6) Some thoughts about implementation
120
121 6 Robin Mills
There is a Memory Mapped IO class in Exiv2.  I think we can use that to implement the HTTP read stuff.  We can allocate memory for the complete file, then populate the memory "just in time" when the user makes a read read.
122 5 Robin Mills
123
The priority is to have HTTP/read support (without copying the whole file).
124
Writing back isn’t so interesting (most HTTP servers don’t allow PUT).
125
Other protocols are interesting, and the "quick and dirty" solution is to copy the complete file.
126
127
This business of only updating those parts of the file which have changed are very effectively implemented by rsync.  Perhaps we should investigate if we can incorporate that in our solution.  I personally update clanmills.com (which has 6GB/100,000+ files) using rsync (over ssh) and I am always astonished by its speed/reliability.