Dear @all,
after talking with Sebastion today, I would recommend restructuring the task as follow:

• Renaming the main task to: AXIOM Beta Webinterface
• Creating a new sub-task: Axiom Beta Webinterface API. The student could implement the API using google protobufs
• Creating a new sub-task AXIOM Beta Webinterface Serverside, using existing code or implementing in different language (e.g. python or go)
• Creating a new sub-task AXIOM Beta Webinterface Clientside

Backend language

As the current implementation has not progressed a lot, I would like to seize the opportunity discussing the current language skill requirements php and javascript. Go and python would offer a very good foundation for implementing the webinterface.

Python for being very readable and having progressed to the most used language on US-american universities. It has great TDD tools and forms a very powerful combination with flask.

However, I think go would be the best language for programming the web interface back end. It is very fast and super suitable for embedded applications. go would offer google code students a lot of opportunities as well, perhaps learning a new, powerful language on the fly. And it obviously comes with Protobuf support.

Frontend language

Vanilla javascript is fine but neglects all those beautiful changes happing the last couple of years. I am guessing discussing a suitable stack would be one of the first steps into this task. Typescript and React should be treated as first class citizens. The new kid on the block clojure is a great language as well, being very hot in the valley at the moment.

I would also like to add that there is no exclusivity with APIs. We can do PHP, python, nodejs, go and bash, etc. APIs and it will make users and developers the happier the more options there are.

This is what I find confusing, alas me recommending the renaming to "AXIOM Beta Webinterface".

It would be great to offer the data in various formats, e.g. JSON, XML, protobuf, you name it. Having multiple implementations of the software providing the data seems like an unnecessary overhead to me.

A word of caution, just because some language is hip at the moment, doesn't mean that the performance or feature set is suited for embedded systems. It should be evaluated first. I still vote for C/C++ for the backend, it maybe complex for some people, but it's giving the most performance (usually).

Besides protobuf there is flatbuf, https://github.com/google/flatbuffers, stumbled over it recently.

All languages mentioned are well tested, providing a rich environment.

Perhaps it's best we break down the task first, providing detailed information about what to do in what step and discuss language specifics at a later time.

You still shouldn't forget, that ARM processors have not infinite resources to process things. If it's possible we should use JIT versions of languages or ones optimized for ARM. Had just a glimpse at it on google while lunch break at work.

First discussions should be about the API itself, as i haven't seen which parts should be covered by it. Then properties should be defined, which should be accessible. And then evaluation can start.

Hi,
I am Anudit Verma, a final year CS undergrad from University School of Information, Communication and Technology (USICT), Delhi, India. I am an avid open source enthusiast and a contributor, always interested in learning something new while contributing significantly to the open source community. I have worked earlier on a GSoC project with CiviCRM, in helping them integrate OSDI API into their system, my project can be seen here. I did most of my project's work in PHP, along with that it include working with JSON & XML data, I also know C/C++, haven't used Google's Protocol Buffers though, but I am very much interested in this project, I might learn something new and exciting. You can know more about me at anudit.in/aboutme
I followed the discussion on this thread, so I am also aware of the fact that we are currently focusing more on the project's tasks and discussing less about which language to be used in order to complete this project, but I have a small doubt here, so is it upon a student to choose the language to go with, which is the part of his skill set ? I completely understand the fact that we are not choosing the ease of code-bility of a student in any language rather we could set a specific language so as to optimise the project itself at the end. Could you please throw more light in this regard ? Also it would be great if you can provide some links of the resources from where I can learn more about the code base of Apertus and start my contributions.

Thanks in advance, looking forward to have more community interactions.

Hello and welcome,

we will discuss this topic step by step, but we need other guys too. Just replying so you know, that someone is available. I've suggested to define the API first, so we can define some boundaries, so the language doesn't matter first. It should be almost the same to translate the requirements to different language. Also had FastCGI on my mind at some point, because the camera firmware already uses lightppd as webserver and it should support it. Just as example -> http://chriswu.me/blog/writing-hello-world-in-fcgi-with-c-plus-plus/.

Sorry, cannot reply longer at the moment, as it's late here (Germany) and my regular job awaits tomorrow.

Best regards

Andrej

Hi again, thanks for the reply Andrej and yes let's see what others have in their mind, meanwhile I will try the example you have mentioned and try to learn more about the project idea itself.
Thanks again, I hope to make some progress very soon.

Anudit

We are currently improving the onboarding process (documentation, tools,..) for this task. I am positive we can give more information on monday. Regarding dates and times: Most of our team lives in MET (UTC +1). We will switch to Daylight saving time (UTC+2) on the 26th of March.

@anuditverma,
Your work on CiviCRM is well documented and easy to read, which is great. Two questions come to my mind:

• Variables like page URL are hard coded. Was this a requirement by CiviCRM or was there just not enough time to generalise?
• Did you think about auto documenting your API with swagger.io? If so, why did you choose not to?

I am very interested in your answers and would be happy to discuss this task further with you.

Hi @maltefiala,

Thanks for your interest in my work, so here are my views to your queries,

"Variables like page URL are hard coded. Was this a requirement by CiviCRM or was there just not enough time to generalise?"

Actually no, It was not sort of a requirement of the overall project, but yeah during the initial days of beginning of the project I worked upon focusing more on hard coding the project extension (please see here), all the work was done from the ground, building the helper pages (which you can see here). Few parts of the coding was done inside a wrapper provided by the CiviCRM CLI tools. Also I would like to mention that initially I had proposed a different project idea to them which was totally different from what I did, so just few days before the application deadline, CiviCRM's GSoC org mentor approached me and asked if I can switch over to a different idea, because one of their mentor was very much interested in implementing OSDI API and since I was equally motivated too, I was selected. So long story short, yes we kind a had very little time in hand to look over other things, I had to re-submit a new proposal with a new approach, new timeline and other expected deliverable(s)

"Did you think about auto documenting your API with swagger.io? If so, why did you choose not to?"

Honestly, I didn't because the documentation I did (here in a README.md) was the part of the "org.civicrm.osdi", yes, you can see that the project was completed as an extension package and it was uploaded to the CiviCRM's extension directory. So it was a predefined format provided by the CiviCRM cli-tools to create a new extension, it provides a skeletal dir structure where you can add/edit licences, xml and other configuration files.

We can actually use swagger to document, if you want me to, I have no issues.

I hope it cleared your doubts, please let me know if you want to know more about me or my work, happy to reply.
Looking for forward to see the tasks, thanks.

@anuditverma, thanks a lot for your detailed answer. I will update this task as soon as we have improved the onboarding process.

@anuditverma, we finished updating this task. If you are still interested, please apply with a timeline proposal until April 3 16:00 UTC. If you have any further question, feel free to ask.

Thanks @maltefiala for the update and for the application reminder, I am looking forward to apply. I will go through this updated task once again to get a more clear understanding to make my basic fundamentals more strong.

Also I have been discussing on the IRC about getting some experience of camera firmware and making example calls for changing parameters on the camera internal command line. As discussed here, I will see if I can get the latest archlinux image running on my Raspberry Pi to setup AXIOM beta software and then try these examples.

Will surely move to IRC or the mailing list if I get stuck, thank you.

Dear @anuditverma, it's great you want to take a look at the current examples. Just bear in mind that the camera hardware has not been virtualised so far, so you won't be able to get useful replies when running the scripts on your raspberry. The latest firmware is here: http://vserver.13thfloor.at/Stuff/AXIOM/BETA/beta_20170109.dd.xz

Please know that knowledge about direct hardware calls is not necessary for this task, as you would use the C library of T758.

Oh alright I see, thanks for the heads up @maltefiala, then I should certainly focus on other aspects of this project.

Offtopic

If you are interested in doing the virtualization, you can take a look at T724, T737 and T738.

I am pretty sure we could merge them into one gsoc task, but that's something @alex and @Bertl would know more about.

Update
I just saw that T724 already is a gsoc task :) . If you prefer doing that, please apply for this task or ask there

Hi @maltefiala,

Since the task has been updated, I have been following the resources present on it, also I am getting my self acquainted with the prerequisites too.
One of the resource link is leading to a O'reilly book "Test-Driven Development with Python" and it is advised to read 1-4 chapters from it, the book contains py and django based app development content.

Could you please let me know if django is needed for this task ? Although my django's knowledge is pretty basic and I have tried it only for making a small app for myself, haven't actually worked on a full fledged production project.

Also I am interested in knowing, how can I setup my development environment ? I am aware of the fact that hardware calls are not required in this task as you have mentioned it earlier, but just for a start if can explore the AXIOM beta software and get some experience.

Thanks in advance.

Just my idea: As the daemon is planned for user-space first, it would be not a big problem to test on local machine. Actually developing it currently on LinuxMint with Unix domain sockets which are meant just for local usage, other languages need wrappers of course to be able to use commands which came over network. Don't want to allow to access the daemon over network for security purpose at the moment.

So the daemon could be extended with more log output to verify right usage and simplify testing.

@anuditverma
No, you don't need to know about django, you only need to know about unit testing. Feel free to consult another resource of your liking.

@BAndiT1983
So, just to make sure: Someone working on this task (T723) will get suitable return values when using the C library of T758, without the need of the actual camera, am I right? Having the daemon of T757 incorporating verbose output would be great indeed!

Yes, if we extend it a bit, just creating a simple daemon for now. The log is written to /var/log/syslog in my VM. You can see the init for log in the source i've uploaded yesterday, jsut take a look at main.cpp. Thanks for reminding me of return values, as we also want to request set values to display/verify them.

Hi,

I have prepared my first draft of the proposal, please review and comment wherever necessary, it will help in improving it more.

Here is the link: AXIOM Beta REST Interface Proposal

Thank you, looking forward to discuss further.

Thanks for your application draft. I will look at it following week. If you don't hear back from me until April 1st, please ping me.

Hi @maltefiala,
Please have a look on my proposal draft, allow me to utilize your valuable feedback to improve it further so that I can upload a final version.
Thank you, waiting for your response.

@anuditverma,
thanks for ping, will answer tomorrow

@anuditverma,
thanks for your application! I just finished looking at it and am looking forward to receive your final application tomorrow.

A note from @sebastian:
We are very happy to see that many of you have already submitted their draft or final proposals via the official GSoC Program website to apertus.

Please note the final deadline for submissions is on Monday.

Google notified us that their system does not allow any late submissions so please dont forget to press that submit button in time :)

Regards Sebastian

Hello @maltefiala,

Thank you for reviewing my proposal. Sorry I wasn't able to respond earlier, I was busy in a 36 hours long 'Smart India Hackathon', it's over now. I would definitely work upon on your suggestions and submit the final proposal into the GSoC system in few hours.

@maltefiala What about Meteor or Dart for the client side? I'm not that deep into web development jungle and if one searches the web, then thousands of frameworks can be found.

@BAndiT1983 As client side looks rather small I would suggest vanilla javascript.

Some recent discourse for posterity:

In emails, Eivind wrote:

I think Go is a good choice, because it's lightweight and can easily manage an http connection without a separate web server. It's also a language that has been designed to be easy to learn, which probably makes it easier to attract and replace contributors as needed. I'd be keen to hear your thoughts though.

For the REST API, I think it's a good idea to design with the consumer in mind, whether that be a different application, like a rich web interface, or a person using it to create something cool, because that often leads to better implementations, in my experience. Examples of what I'd consider a good API for getting/setting a specific property:

GET /device/feature # returns all properties of feature
PUT /device/feature?property=value # sets property of feature

Where device might be a module and there'd be several feature modules for different http verbs and Accept headers, like JSON, XML, etc. I don't know how to best achieve this in Go, or for this project specifically, but I'm just throwing out some ideas in case they are of use.

In emails, @BAndiT1983 wrote:

It's not a big problem to get it modular, as the server will consist of 2 modules at least: socket (mainly to daemon at the moment) and REST/HTTP one. Further ones can be added on demand.

In emails, @sebastian wrote:

I can help with that, with how/where to set/get parameters/registers, how to convert them to human readable formats and valid ranges, etc.

Lets just start with a few simple parameters first (like setting analog gain) and then work our way along the things the camera/senor provides.

In emails, @BAndiT1983 wrote:

First plan was to use a C/C++ (static) lib, so any client can re-use the same interface without re-inventing it. But at some point people wanted Go (modern stuff and other reasons), so the client was implemented in it, nevertheless the original C/C++ one will still be there.

I've already done some tests in Go which include REST, daemon communication through flatbuffers and Unix Domain Sockets (later it will be managed through systemd). Next todo on the list is to specify who provides the list of available parameters, currently i'm focusing on some JSON file, which provides additional informations like ranges and so on.

We should define where the data comes from, e.g. JSON file, then we should define a format. Afterwards i can extend basic provider which uses this data and not some pre-defined one which is currently sent through the Go REST prototype. If everything is there, at least stable, then we can merge it with the Go server.

Additionally, as far as there is some spare time, investigation about systemd, daemonization and socket activation is ongoing.

In emails, @flesk wrote:

Daemonizing the Go application with systemd should be fairly easy. I've done so with RESTful Java applications with embedded servlet containers, and I imagine this will be similar. I don't know if enabling sockets adds additional complexity though.

Is the source your prototype application available somewhere?