On 22 April 2018 at 10:57, Jan Iversen <[email protected]> wrote:
>
>
>> On 22 Apr 2018, at 11:33, sebb <[email protected]> wrote:
>>
>> On 22 April 2018 at 09:54, Jan Iversen <[email protected] 
>> <mailto:[email protected]>> wrote:
>>>
>>>
>>>> On 22 Apr 2018, at 10:17, sebb <[email protected]> wrote:
>>>>
>>>> On 21 April 2018 at 12:57,  <[email protected]> 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?<project>
>>>>
>>>> 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.

I am not convinced that your solution works for all the existing pages
and for retaining URLs.

> The real key here which person will do the maintenance in the future.

Indeed.

> 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.

I have also done some of the Attic work (e.g. I recovered the missing
Jakarta sites from the Internet Archive) but have not done any
recently.

I am not trying to make your work harder, but I am trying to come up
with a solution that is externally compatible (no broken URLs, no
missing information) and which is easy to maintain.

>>
>> 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 
> <http://www.attic.org/test.html>

I meant that one needs to test all the pages and the redirect.

The existing test only works for one static page (i.e. the home page).

>>
>>>>
>>>>> - 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.

I meant Jakarta Taglibs

http://attic.apache.org/projects/jakarta-taglibs.html

>>
>>>
>>>> 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.

HTML 1 is a strawman argument.

At the very least the user needs to be told that there is missing
information if they don't have Javascript.

> 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.
>

Reply via email to