Re: GSoC - Octave code sharing

[siko1056]

Ankit wrote
> On Wed, Apr 18, 2018 at 10:28 PM, Sahil <

> yadavsahil5198@

> > wrote:
> 
>> Hello Kai
>>
>> I've sent the trailing mail to 

> octave-maintainers@

>  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 <

> yadavsahil5198@

> > 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/1InJhgZQkW61a42qPwiIW
>>> jYz7xPo4Gk9fKhsdrd3G_7M/edit?usp=sharing
>>>
>>> ---------- Forwarded message ----------
>>> From: Kai Torben Ohlhus <

> k.ohlhus@

> >
>>> Date: 17 April 2018 at 13:03
>>> Subject: Re: GSoC - Octave code sharing
>>> To: Sahil <

> yadavsahil5198@

> >
>>> Cc: Ankit Raj <

> aktjha@

> >
>>>
>>>
>>> Greetings Sahil,
>>>
>>> On Sun, Apr 15, 2018 at 6:44 PM Sahil <

> yadavsahil5198@

> > 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
>>>> <https://siko1056.github.io/blog/2017/03/10/getting-to-know-the-mediawiki-api.html>
>>>> .
>>>>
>>>
>>> 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/C
>>> <https://wiki.octave.org/Agora_Octave>ode_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 <https://github.com/octave-de/octave-web>. I have a
>>>> few
>>>> questions:
>>>>
>>>> 1. There's this second subpoint of the second point in this
>>>> <https://github.com/octave-de/octave-web#things-to-improve> :
>>>>
>>>>> 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
>>> <https://github.com/octave-de/OctConf2017/blob/master/demo2/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
>>>> <https://rawgit.com/siko1056/Octconf2017/master/octconf2017-publish-ohlhus-slides.pdf#page=8>
>>>>  when we are using the libcurl_wrapper in        the functions
>>>> mentioned in point 2.
>>>>
>>>
>>> For now this file publishToWiki.m
>>> <https://github.com/octave-de/OctConf2017/blob/master/demo2/publishToWiki.m>
>>> uses
>>> the system shell (e.g. the bash script wikiLogin.sh
>>> <https://github.com/octave-de/OctConf2017/blob/master/demo2/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
>>> <https://github.com/octave-de/OctConf2017/blob/master/demo2/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
>>>> <https://github.com/octave-de/OctConf2017/tree/master/demo2> 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
>>>
>>> **************************************
>>>
>>
>>
> 
> Hello Sahil,
> 
> 
> I have gone through your timeline. IT looks good and achievable from my
> side. It would be great if you include the testcases there which you
> wanted
> to write.
> 
> Thanks,
> Ankit Raj


Sahil,

Thank you for the detailed timeline.  I added some comments.  A short
summary:

- Devote more time (> 4 weeks) to the implementation of the libCURL wrapper,
weboptions.m, webread.m, webwrite.m, websave.m (in the given order).  The
communication with the MediaWiki (login, etc.) relies on those functions to
work.

- We need to setup a test MediaWiki (I can provide some installation, when
you start testing).

Another thing I did not mention is, that we need to handle JSON-data. 
Currently Octave does not support `json(en/de)code` [1] and (bug #53100),
but we can make use of jsonlab in the meantime [2], which is pure m-code,
thus easily replaceable but not high-performance.

Kai.

[1] https://www.mathworks.com/help/matlab/ref/jsondecode.html
[2] https://github.com/fangq/jsonlab



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html