Re: Discussion on proposed solutions for simplified maintenance.

[sebb]

On 22 April 2018 at 11:12, Henk P. Penning <penn...@uu.nl> wrote:
> On Sun, 22 Apr 2018, Jan Iversen wrote:
>
>> Date: Sun, 22 Apr 2018 11:57:33 +0200
>> From: Jan Iversen <jancasacon...@gmail.com>
>> To: general@attic.apache.org
>> Subject: Re: Discussion on proposed solutions for simplified maintenance.
>
>
>>> On 22 Apr 2018, at 11:33, sebb <seb...@gmail.com> wrote:
>
>
>>> For proper comparison I think we need to see the whole solution.
>>> This will obviously have to be done so that it does not impact the live
>>> site.
>>
>> I believe the sample I have made with test.html and generation of all
>> project files are sufficient. No need to waste more time on that. Time
>> saving is important to me, and it does not make sense to waste
>> resources on making two complete solutions just to scrap one of them.
>
>
>   Right ; I think Jan's stuff is ok ; basicly it doesn't have
>   to be more complicated than that. It is a good starting
>   point for further development.

It does not (yet) handle all the existing information on Attic website.
Nor does it yet keep the URLs unchanged.

I think think it would be wrong to replace the existing site until
that has been addressed.
Which is why I think there should be a PoC that can be tested.

I will create a new branch so the existing proposal can be developed further.

>   Personally I would separate the (json) data from the program,
>   but that is a minor detail.

Agreed; if JSON is to be used it should be in a separate file.

>   Regards,
>
>   Henk Penning
>
>    _
> Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
> Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
> Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
> http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/

Re: Discussion on proposed solutions for simplified maintenance.

[Henk P. Penning]

On Sun, 22 Apr 2018, Jan Iversen wrote:


Date: Sun, 22 Apr 2018 11:57:33 +0200
From: Jan Iversen <jancasacon...@gmail.com>
To: general@attic.apache.org
Subject: Re: Discussion on proposed solutions for simplified maintenance.



On 22 Apr 2018, at 11:33, sebb <seb...@gmail.com> wrote:



For proper comparison I think we need to see the whole solution.
This will obviously have to be done so that it does not impact the live site.

I believe the sample I have made with test.html and generation of all
project files are sufficient. No need to waste more time on that. Time
saving is important to me, and it does not make sense to waste
resources on making two complete solutions just to scrap one of them.


  Right ; I think Jan's stuff is ok ; basicly it doesn't have
  to be more complicated than that. It is a good starting
  point for further development.

  Personally I would separate the (json) data from the program,
  but that is a minor detail.

  Regards,

  Henk Penning

   _
Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/

Re: Discussion on proposed solutions for simplified maintenance.

[Jan Iversen]

> On 22 Apr 2018, at 11:33, sebb  wrote:
> 
> On 22 April 2018 at 09:54, Jan Iversen  > wrote:
>> 
>> 
>>> On 22 Apr 2018, at 10:17, sebb  wrote:
>>> 
>>> On 21 April 2018 at 12:57,   wrote:
 Hi.
 
 After having studied the solution proposed by Sebb, I have decided to add 
 my proposal again.
 
 My proposal has one outstanding TODO:
 - add a .htaccess to projects that catches * and redirect to 
 attic.js?
>>> 
>>> That needs testing to ensure it works properly.
>> Just as with your solution, testing is always needed. That is the reason I 
>> did not touch any production files, but added test.html
> 
> For proper comparison I think we need to see the whole solution.
> This will obviously have to be done so that it does not impact the live site.
I believe the sample I have made with test.html and generation of all project 
files are sufficient. No need to waste more time on that. Time saving is 
important to me, and it does not make sense to waste resources on making two 
complete solutions just to scrap one of them.

The real key here which person will do the maintenance in the future. As the 
person who have done the maintenance in the past and if nothing changes will 
continue to do so, I believe it is fair to make a system that makes my life 
easier. If of course needs to be a system, that can be easy handled in case I 
need a substitute. In the case I am not supposed to do the maintenance in the 
future my opinions carry a lot less weight.

> 
> Which is why I created the branch; this contains everything needed to
> set up the website.
> I have been able to test it locally.
Well you can also test it live, as I do www.attic.org/test.html 


> 
>>> 
 - change attic.js to use project name instead of a number
 Apart from that my solution is working, and seen from the outside the 
 Attic site is identical, responding to the same url as before.
>>> 
>>> Apart from:
>>> The non-project HTML file resolution.html does not use the new list of 
>>> projects
>> It will, look in test.html then you can see how that will be done in the 
>> production files that non-project.
>> 
>>> The project/* files don't allow for additional info such as is present
>>> in some of the existing XML files
>> It actually does, just add that information to the description field.
> 
> OK, so try that with Taglibs.
Quite hard to do, as we do not have Taglibs as a retired project.

> 
>> 
>>> The site does not work if a client does not support Javascript
>> Correct, but nowadays that is hardly a problem.
> 
> We still need to support such clients.
I beg to differ. We also do not support all old browser applications (like the 
ones who only support HTML 1), somewhere you have to set a limit.

rgds
Jan I.

> 
>>> 
 The proposal from Sebb, involves new technology (Jekyll, YAML, bot) as 
 well as a markdown file pr project and are also working.
 
 Can we please have an open discussion to choose between these 2 variants 
 and if needed (which I hope we can avoid) a vote.
 
 —
 My pow:
 
 JS is not the best solution I preferred PHP, but needed in order to have a 
 static server side. The JSON embedded in attic.js is valid json, and easy 
 to extract with a simple sed, should anybody need it.
 
 The solution from Sebb introduces a number of new technologies, and adds a 
 bot that runs and eat resources.
 
 As the one who have done the maintenance the last year, I look for a 
 solution where we update a single file, and avoid complications (like 
 looking after a build job).
 
 —
 
 Please add your comments and let aim at making a decision this month.
 
 Have a nice weekend
 rgds
 Jan I.

Re: Discussion on proposed solutions for simplified maintenance.

[sebb]

On 22 April 2018 at 09:54, Jan Iversen  wrote:
>
>
>> On 22 Apr 2018, at 10:17, sebb  wrote:
>>
>> On 21 April 2018 at 12:57,   wrote:
>>> Hi.
>>>
>>> After having studied the solution proposed by Sebb, I have decided to add 
>>> my proposal again.
>>>
>>> My proposal has one outstanding TODO:
>>> - add a .htaccess to projects that catches * and redirect to 
>>> attic.js?
>>
>> That needs testing to ensure it works properly.
> Just as with your solution, testing is always needed. That is the reason I 
> did not touch any production files, but added test.html

For proper comparison I think we need to see the whole solution.
This will obviously have to be done so that it does not impact the live site.

Which is why I created the branch; this contains everything needed to
set up the website.
I have been able to test it locally.

>>
>>> - change attic.js to use project name instead of a number
>>> Apart from that my solution is working, and seen from the outside the Attic 
>>> site is identical, responding to the same url as before.
>>
>> Apart from:
>> The non-project HTML file resolution.html does not use the new list of 
>> projects
> It will, look in test.html then you can see how that will be done in the 
> production files that non-project.
>
>> The project/* files don't allow for additional info such as is present
>> in some of the existing XML files
> It actually does, just add that information to the description field.

OK, so try that with Taglibs.

>
>> The site does not work if a client does not support Javascript
> Correct, but nowadays that is hardly a problem.

We still need to support such clients.

>>
>>> The proposal from Sebb, involves new technology (Jekyll, YAML, bot) as well 
>>> as a markdown file pr project and are also working.
>>>
>>> Can we please have an open discussion to choose between these 2 variants 
>>> and if needed (which I hope we can avoid) a vote.
>>>
>>> —
>>> My pow:
>>>
>>> JS is not the best solution I preferred PHP, but needed in order to have a 
>>> static server side. The JSON embedded in attic.js is valid json, and easy 
>>> to extract with a simple sed, should anybody need it.
>>>
>>> The solution from Sebb introduces a number of new technologies, and adds a 
>>> bot that runs and eat resources.
>>>
>>> As the one who have done the maintenance the last year, I look for a 
>>> solution where we update a single file, and avoid complications (like 
>>> looking after a build job).
>>>
>>> —
>>>
>>> Please add your comments and let aim at making a decision this month.
>>>
>>> Have a nice weekend
>>> rgds
>>> Jan I.
>

Re: Discussion on proposed solutions for simplified maintenance.

[Jan Iversen]

> On 22 Apr 2018, at 10:17, sebb  wrote:
> 
> On 21 April 2018 at 12:57,   wrote:
>> Hi.
>> 
>> After having studied the solution proposed by Sebb, I have decided to add my 
>> proposal again.
>> 
>> My proposal has one outstanding TODO:
>> - add a .htaccess to projects that catches * and redirect to 
>> attic.js?
> 
> That needs testing to ensure it works properly.
Just as with your solution, testing is always needed. That is the reason I did 
not touch any production files, but added test.html

> 
>> - change attic.js to use project name instead of a number
>> Apart from that my solution is working, and seen from the outside the Attic 
>> site is identical, responding to the same url as before.
> 
> Apart from:
> The non-project HTML file resolution.html does not use the new list of 
> projects
It will, look in test.html then you can see how that will be done in the 
production files that non-project.

> The project/* files don't allow for additional info such as is present
> in some of the existing XML files
It actually does, just add that information to the description field.

> The site does not work if a client does not support Javascript
Correct, but nowadays that is hardly a problem.

> 
>> The proposal from Sebb, involves new technology (Jekyll, YAML, bot) as well 
>> as a markdown file pr project and are also working.
>> 
>> Can we please have an open discussion to choose between these 2 variants and 
>> if needed (which I hope we can avoid) a vote.
>> 
>> —
>> My pow:
>> 
>> JS is not the best solution I preferred PHP, but needed in order to have a 
>> static server side. The JSON embedded in attic.js is valid json, and easy to 
>> extract with a simple sed, should anybody need it.
>> 
>> The solution from Sebb introduces a number of new technologies, and adds a 
>> bot that runs and eat resources.
>> 
>> As the one who have done the maintenance the last year, I look for a 
>> solution where we update a single file, and avoid complications (like 
>> looking after a build job).
>> 
>> —
>> 
>> Please add your comments and let aim at making a decision this month.
>> 
>> Have a nice weekend
>> rgds
>> Jan I.