Week 11

This week I fixed some styling in the previous codebase and other minor issues. Me and Kai had a very fruitful discussion this week for the roadmap ahead. We discussed many things.

Kai verified that wiki_upload.m (an important dependency for publish_to_wiki.m) works as expected including the checks for uploading the same image again, wikimedia itself does a hashcheck before uploading and sends an error if the image is identical to the previous one or a warning if the image already exists on the wiki server. You can check this by calling:

publish_to_wiki ("script", "username", "password")

where script, username and password correspond to the script that you want to publish, your username and password for wiki.octave.space (this will be changed to wiki.octave.org later) respectively. One problem that I noted was Octave hangs up if the connection gets lost in the middle of the transfer. But this is not native to this function, it affects all the files that require to use libcurl’s interface to Octave. Nevertheless, I tried to look into it, with the function CURLOPT_TIMEOUT and other, as well. Unfortunately, I couldn’t get a viable answer because the timeout value in the above function is measured from the start of the transfer and NOT when the connection gets lost. So suppose if someone has a large transfer, then setting this value is potentially dangerous because their tansfer will get cancelled in the middle of the process even though the connection is good. Other than this, there were provisions to exit the API if the speed gets below a given threshold. This again cannot be guaranteed because it might be that the user may have a lesser internet speed. So, the idea of resuming Octave was dropped altogether, its again upto the user to get a proper internet connection! Other than this, there was the quest of making test cases for wiki_upload.m for which I suggested to measure the Content-Length of the query string that is formed as part of the transfer. This again has problems, because the libcurl API for Octave doesn’t let the developer know the actual query string which is transferred over the connection. FYI, the query string formation takes place here. This would only add a big overhead for the returned values from the C++ API to the Octave code because all of the functions that use the perform () (it actually performs the transfer) function will need to be changed. I initially had suggested this because during debugging I had actually changed the form_query_string function according to my needs. But then I realised that this is not feasible because:

• As mentioned above, there would be unnecessary overhead to change all the functions because of change in form_query string function. Also, a number of other already implemented functions use it. So, regression can occur.

• We actually cannot measure the actual Content-Length properly, because the content is sent in UTF-8 format which replaces all the non-alphabetical characters with their UTF-8 version. So a whitespace is changed to %20. Of course there are other ways to measure the UTF values for all the characters by running various for loops and adding offsets to a given values to find another value, etc. But I do not think this is a good measure to test the main working of wiki_upload which essentially needs to check if the file has been uploaded or not on the wiki.

Will see if there’s anything else I could do about this, else I will need to manually check at various times if the file has been uploaded correctly or not.

Lastly, the commenting part, which I don’t want to loose marks for, is left and I’ll be doing that in the coming days, before the evaluation so that Kai doesn’t get a chance to bash me on this. ;-)

THIS COMPLETES THE FIRST HALF OF THE PROJECT, i.e., OCTAVE CODE SHARING.

Next lined up is, setting up RESTful web services for Octave.

We had a good discussion over this too. First to be implemented is, weboptions. I initially thought of implementing it using a struct in the backend. But then Kai suggested to use Classdef in Octave and making an object. Of course, he was right, one simple and foolish reason being, weboptions in MATLAB doesn’t display the Password field and if struct is deployed for this, there’s no way that the password is stored in a plain text and displayed as obscured.

Here is what I’ve implemented for this. It almost acts like the weboptions in Matlab with subtle differences. For example, when you call the following, it will show the answer that follows:

>>    d = weboptions

      <object weboptions>

MATLAB shows the values of the fields instead. For that I’ve created a method values so that when you call d.values or values(d), you get to see all the values that are set for the object. There are a few problems which will most probably get rectified as me and Kai have another meeting on IRC. Basically, I’ll need to find a way to represent cell string in it’s input form, i.e, something like

 ans =   {"foo", "bar"}

and not

ans =
    {
        [1,1] = "foo"
        [1,2] = "bar"
    }

You can set values for the various fields and members in the object by calling d.field_name = your_desired_value;. This will do as desired. Some of the fields are currently for the MATLAB compatiblity and will be dealt with later, like ContentReader, MediaType, CertificateFilename, etc.

Oh and kindly strip your latest commit on ocs (a merge commit) in your local repo, else it’ll create a new head. Sorry about that!

Wrapping up for now! Apologies for such a long post.

Link to BitBucket repo.