Hi Ricardo,

I agree with your point of view on the interface implementation approaches.
Indeed, the approaches are not supposed to be mutually exclusive. As you
said the first approach is easier and I have started working closer to this
approach.

I have already created a small module implementing basic HTML templates in
Scheme. Also, I have made an extension to the Cuirass Web API. It responds
on the "/status" request and generates a page with a minimalistic HTML
table displaying the list of specifications stored in the database.

My login on Savannah is "TSholokhova". I am looking forward to making my
first commit. I would be glad to receive comments on my code to be sure
that I am moving in the right direction.

You have mentioned that many users would prefer an interface working
without javascript running. Am I right that we would like to have a
non-interactive (js-free) interface working and also add some functionality
(e. g. search tools for tables) via javascript?

Also, I have a couple of questions regarding the frontend part. What
frontend framework we would prefer? If I get it right, Hydra uses
Bootstrap. For the frontend implementation, we need to include some static
css&js files in the interface and serve them somehow. Is it a good idea to
serve the static files by Cuirass web server in Scheme?

Best regards,
Tatiana

2018-05-18 23:35 GMT+03:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Hi Tatiana,
>
> > I have started thinking about the type of web interface we want to have
> for
> > Cuirass in this project. As far as I see, there are two options:
> >
> >    - a web application served by Cuirass web server;
> >    - a standalone static site which sends queries to the Cuirass web API
> >    (this is similar to Danny's application);
> >
> > I suppose that the first option has more benefits since it allows to
> choose
> > the exact type of information required to be extracted from the database
> by
> > a specific part of the web interface. What do think regarding these
> options?
>
> You are free to extend the Cuirass web API to suit your application’s
> needs.  Having a standalone site is a valid way of providing a web
> interface, but it doesn’t have to be the only way of accessing the
> information.
>
> Even if you go for the first route, the HTML you serve could talk to the
> API.  These two options don’t have to be mutually exclusive.
>
> FWIW, I expect the first approach to be easier because you can use
> Scheme for the most part; the pages it serves could be progressively
> enhanced with JavaScript, if the client supports it.  I’m sure there are
> many users who would prefer a system that would work fine even without
> running JavaScript in the browser.
>
> > How will we organize the development process? More precisely, where
> > should I place the implemented code in order to provide access to it
> > for our team? In my experience, I have used to create the separate
> > branch in the git repository. I would like to know which way of doing
> > this you would prefer.
>
> I forgot how we did this for past GSoC, but my preference is to do this
> in a separate branch of the Cuirass git repository.  Do you have an
> account on Savannah yet?  Once you do we could give you permissions to
> push your work to a separate branch on the repository.
>
> (You are free to host the code elsewhere as long as we have read
> access via git.)
>
> --
> Ricardo
>
>
>