From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tatiana Sholokhova Subject: Re: GSoC: Adding a web interface similar to the Hydra web interface Date: Tue, 22 May 2018 00:52:32 +0300 Message-ID: References: <87vac3twbe.fsf@gnu.org> <87o9hog2ye.fsf@elephly.net> <87d0xyn9zs.fsf@elephly.net> <87d0xswvls.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a30c43056cbe515a" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41428) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fKsjO-0001nl-7T for guix-devel@gnu.org; Mon, 21 May 2018 17:52:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fKsjM-0004cI-Ni for guix-devel@gnu.org; Mon, 21 May 2018 17:52:38 -0400 In-Reply-To: <87d0xswvls.fsf@elephly.net> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: guix-devel --000000000000a30c43056cbe515a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 : > > 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 AP= I > > (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 databas= e > 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=E2=80= =99s > needs. Having a standalone site is a valid way of providing a web > interface, but it doesn=E2=80=99t have to be the only way of accessing th= e > information. > > Even if you go for the first route, the HTML you serve could talk to the > API. These two options don=E2=80=99t 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=E2=80=99m sure th= ere 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 > > > --000000000000a30c43056cbe515a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ricardo,

I agree with you= r point of view on the interface implementation approaches. Indeed, the app= roaches are not supposed to be mutually exclusive. As you said the first ap= proach is easier and I have started working closer to this approach.=C2=A0<= /div>

I have already created a small module implementing= basic HTML templates in Scheme. Also, I have made an extension to the Cuir= ass 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.=C2=A0

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 movin= g 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 w= orking and also add some functionality (e. g. search tools for tables) via = javascript?=C2=A0

Also, I have a couple of questio= ns 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 the= m somehow. Is it a good idea to serve the static files by Cuirass web serve= r in Scheme?=C2=A0

Best regards,
Tatiana=

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

Hi Tatiana,

> I have started thinking about the type of web interface we want to hav= e for
> Cuirass in this project. As far as I see, there are two options:
>
>=C2=A0 =C2=A0 - a web application served by Cuirass web server;<= br> >=C2=A0 =C2=A0 - a standalone static site which sends queries to the Cui= rass web API
>=C2=A0 =C2=A0 (this is similar to Danny's applicat= ion);
>
> I suppose that the first option has more benefits since it allows to c= hoose
> the exact type of information required to be extracted from the databa= se by
> a specific part of the web interface. What do think regarding these op= tions?

You are free to extend the Cuirass web API to suit your application= =E2=80=99s
needs.=C2=A0 Having a standalone site is a valid way of providing a web
interface, but it doesn=E2=80=99t have to be the only way of accessing the<= br> information.

Even if you go for the first route, the HTML you serve could talk to the API.=C2=A0 These two options don=E2=80=99t 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.=C2=A0 I=E2=80=99m 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<= br> > this you would prefer.

I forgot how we did this for past GSoC, but my preference is to do t= his
in a separate branch of the Cuirass git repository.=C2=A0 Do you have an account on Savannah yet?=C2=A0 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



--000000000000a30c43056cbe515a--