Re: GSoC - Octave code sharing

[Sahil]

Hello Kai

I've sent the trailing mail to address@hidden but idk why it's not showing up in the archive as well as nabble. Can you please see how can I get this conversation to the mailing list? 

Thanks

Sahil

PS: I've made the time frame for the project for your review.

On 18 April 2018 at 21:39, Sahil <address@hidden> wrote:

Hi Kai

I've made a timeline for octave code sharing. I've given a Google Doc link in my User Profile page (https://wiki.octave.org/User:Batterylow) on octave so that anyone can directly comment on the exact line/section. Alternatively, anyone can view the same link [1] here. Please have a look at my proposed path and suggest your valuable inputs. 

Thanks and Regards

Sahil

[1] https://docs.google.com/document/d/1InJhgZQkW61a42qPwiIWjYz7xPo4Gk9fKhsdrd3G_7M/edit?usp=sharing

---------- Forwarded message ----------
From: Kai Torben Ohlhus <address@hidden>
Date: 17 April 2018 at 13:03
Subject: Re: GSoC - Octave code sharing
To: Sahil <address@hidden>
Cc: Ankit Raj <address@hidden>

Greetings Sahil,

On Sun, Apr 15, 2018 at 6:44 PM Sahil <address@hidden> wrote:

Hello Kai

I started by first learning RESTful web services. I followed some blog post about deploying a web application based on Apache Maven. That being done, I tried to deploy one other app based on Apache Tomcat server. I had some problems with the second approach (some java class was not being on the config path, but I got it working after a few hours of fidgetting around the directory structure.) I learnt about various methods, error types and terms associated with the HTTP requests that REST makes and saw how they actually work. Read about the MediaWiki introduction that you've written. 

I think dealing with Apache Tomcat and alike is a bit overkill for this particular project, but maybe interesting for you.  Just to be clear: we do have already a webserver (that one https://wiki.octave.org is running or https://nbviewer.jupyter.org/, depending on a decision we will do in the next days) and the major task I imagine is "How to communicate with the existing webserver?".   Therefore I use the term "RESTful", because it just means to give the stateless HTTP protocol some state via cookies to enable logins for MediaWiki installations.

Until you are accepted, I suggest the following steps:

1. All following communication should be moved back to the maintainers mailing list.

 

2. The project outline (the task for the code sharing project should be updated in your blog, https://wiki.octave.org/User:Batterylow, or [https://wiki.octave.org/Agora_Octave --> redirected to something like https://wiki.octave.org/Code_sharing])  A good starting point is the content of your project proposal.

Now regarding your questions:

 

That being said, I also understood the existing curl wrapper that you've already written and executing it after making some amendment, from your repository. I have a few questions:

1. There's this second subpoint of the second point in this :

It should be possible to opt it's functionality out, even after Octave was built, without making it useless.

    Does it means that we should be able to 'toggle' the connection to wiki.octave.org or should it be able to ? 'publish' and 'grabcode' should remain          as it is for this, I believe? 

 

This project is more Octave core related.  My imagined scenario is, that you can delete for example "__curl_wrapper__.oct", with Octave just detecting thi.  Maybe some security admin doesn't want Octave being able to connect to the internet and decides to delete this wrapper in his installation to ensure this.  This is very low priority.

2. Kindly correct me if I am wrong, we will need to inculcate the RESTful services in the following yet-to-implement functions:

   web, webread, webwrite, websave, weboptions,sendmail.

    The libcurl wrapper should be used by the above mentioned functions, right?

Not all of them are required for the project (your time is limited), but any implementation of the wrapper should aim for compatibility of this MATLAB interface.

 

3. I do not think there should be a need to change 'publish' and 'grabcode'. Can we simply use 'output_format' field as 'xml' and use its output to get        the RESTful service work?

We might later use some function like publishToWiki.m to upload the mediawiki formatted file to https://wiki.octave.org.

  

4. It would be really helpful to me if you can help me understand how is cURL interacting with wikiLogin.sh when we are using the libcurl_wrapper in        the functions mentioned in point 2.

For now this file publishToWiki.m uses the system shell (e.g. the bash script wikiLogin.sh) to get it's work done.  THIS IS YOUR PROJECT!  Last year, I started an attempt using Java to do the RESTful login to the wiki wiki_login.m, which is incomplete.  Instead of Java a more ambitioned project is not to just make this particular use case work, moreover to use libCURL to teach Octave itself to do RESTful (e.g. cookies) connections to an existing webserver.

 

5. Since 'urlread' cannot handle session cookies, will we need to save the cookies in the octave workspace itself?

If you decide to implement the functions of your point 2. Then the session handling will be controlled by these functions (the Octave workspace will just get a handle to the connection itself).  All the connection associated data will be implicitly available from that connection handle and the user should not care about them.

 

6. Do I need to touch theseambitioned files or everything is to be done on the functions in point 2 and the libcurl wrapper? Most of them will ease my work, I              believe.

 

All in all, from what I've gathered, the path looks something like this for the project:

1. Create an interface between libcurl (by implementing octave::curl_transfer ?) and publish() and provide an abstraction to it in the form of a single function to publish it on https://wiki.octave.org/Agora_Octave.

2. Create the RESTful web services for octave which could be flexibly (by a user's will) used by the functions mentioned in point 2 above.

3. Come up with a solution to store session cookies.

See my previous answers.

 

This is what all I could get by reading your email:

 Regarding the project I figured out last year was to "misuse" the 
possibilities of MediaWiki to easily store Octave functions and scripts 
(including MediaWiki's version control and nice builtin code presentation) 
by using "publish" and "grabcode" from GNU Octave to 
https://wiki.octave.org. 

The major work of this project was to "teach" Octave the RESTful web service 
functions [2] (especially cookies using libcurl or alike).  The syntax 
highlighting etc. is already included into GNU Octave and the MediaWiki 
part.  There is NO need to establish a new website (e.g. Agora) 

and your Oct Conf slides. I'm really sorry if I interpreted it in some other way or if there's something horribly wrong in the above written approach and questions. I would be really glad if you could help me in getting the right directions and major changes which I deduced that need working upon. 

I may set up a proper timeline if you believe my understanding for the project is fine.

Any other advice is wholeheartedly welcomed. 

Thanks for your time.

Regards 

-- 

*************************************

Sahil Yadav
Bachelor (III) in Computer Science and Engineering
Indian Institute of Technology, Mandi(H.P.), India - 175005

 

**************************************

I think we start with a detailed project outline in the wiki or blog as basis for further discussions.

Best,

Kai 

-- 

*************************************

Sahil Yadav
Bachelor (III) in Computer Science and Engineering
Indian Institute of Technology, Mandi(H.P.), India - 175005

**************************************