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.
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?
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
I think we start with a detailed project outline in the wiki or blog as basis for further discussions.
Best,
Kai