Second proposal for new site maintenance.

[jani]

Hi

I have given some thought to the proposal by Sebb that replaces my proposal.

There have been on/off talks over a long time about simplifying the 
maintenance, common for the talks are the wish to only maintain a single file, 
preferable json format.

The proposal from Sebb have a lot of good qualities, but the latest suggestion 
is a file pr project combined with yaml files, this is far from the original 
wish and something I cannot support. I am also a bit concerned about having a 
bot running for something that changes 3-4 times pr year, it seem like a waste 
of Infra resources.

It is important that the maintenance can be carried out easily and it is 
important that the look/feel of the site stays identical e.g. old urls must 
remain available. Adding a struct in a json file secures easy maintenance, as 
in the original proposal.

Please let us not complicate things. This started because I wanted to simplify 
my life and have grown into something bigger. Bigger might be better, but is it 
really needed, and are there somebody willing to do our job (move retired 
project to the Attic) ?

rgds
Jan I.

Re: Second proposal for new site maintenance.

[sebb]

On 20 April 2018 at 12:11,   wrote:
> Hi
>
> I have given some thought to the proposal by Sebb that replaces my proposal.
>
> There have been on/off talks over a long time about simplifying the 
> maintenance, common for the talks are the wish to only maintain a single 
> file, preferable json format.

Why is a single file necessary?

> The proposal from Sebb have a lot of good qualities, but the latest 
> suggestion is a file pr project combined with yaml files, this is far from 
> the original wish and something I cannot support.

Why not?

> I am also a bit concerned about having a bot running for something that 
> changes 3-4 times pr year, it seem like a waste of Infra resources.

This same bot is used for lots of sites.

> It is important that the maintenance can be carried out easily and it is 
> important that the look/feel of the site stays identical e.g. old urls must 
> remain available.

Agreed.

> Adding a struct in a json file secures easy maintenance, as in the original 
> proposal.

I disagree that JSON is the way to go.

> Please let us not complicate things.

JSON is complicated to use with anything other than small amounts of
textual data.

> This started because I wanted to simplify my life and have grown into 
> something bigger.

> Bigger might be better, but is it really needed, and are there somebody 
> willing to do our job (move retired project to the Attic) ?

Personally, I would much rather create/edit a single YAML file per
project than a large slab of JSON.

> rgds
> Jan I.

Re: Second proposal for new site maintenance.

[Jan Iversen]

> On 22 Apr 2018, at 09:43, sebb  wrote:
> 
> On 20 April 2018 at 12:11,   wrote:
>> Hi
>> 
>> I have given some thought to the proposal by Sebb that replaces my proposal.
>> 
>> There have been on/off talks over a long time about simplifying the 
>> maintenance, common for the talks are the wish to only maintain a single 
>> file, preferable json format.
> 
> Why is a single file necessary?
> 
>> The proposal from Sebb have a lot of good qualities, but the latest 
>> suggestion is a file pr project combined with yaml files, this is far from 
>> the original wish and something I cannot support.
> 
> Why not?
Because it is multiple files instead of 1 file. You need to edit the .md, which 
eventually will lead to different content/look&feel project files (with content 
I mean different classes of content, like some will have related projects 
others will not even have the field…also with .md it is possible to reorder the 
information).

> 
>> I am also a bit concerned about having a bot running for something that 
>> changes 3-4 times pr year, it seem like a waste of Infra resources.
> 
> This same bot is used for lots of sites.
> 
>> It is important that the maintenance can be carried out easily and it is 
>> important that the look/feel of the site stays identical e.g. old urls must 
>> remain available.
> 
> Agreed.
> 
>> Adding a struct in a json file secures easy maintenance, as in the original 
>> proposal.
> 
> I disagree that JSON is the way to go.
> 
>> Please let us not complicate things.
> 
> JSON is complicated to use with anything other than small amounts of
> textual data.
Not really, at least not from my pow, and after all I just converted all 
projects to json, that should count for some experience.

> 
>> This started because I wanted to simplify my life and have grown into 
>> something bigger.
> 
>> Bigger might be better, but is it really needed, and are there somebody 
>> willing to do our job (move retired project to the Attic) ?
> 
> Personally, I would much rather create/edit a single YAML file per
> project than a large slab of JSON.
YAML would solve the problem of a single file, but for that you need to think 
about how to online validate the file, before committing. As a personal opinion 
I find YAML with its less restrictive format a lot more error prone.


rgds
Jan I.
> 
>> rgds
>> Jan I.

Re: Second proposal for new site maintenance.

[sebb]

On 22 April 2018 at 09:51, Jan Iversen  wrote:
>
>
>> On 22 Apr 2018, at 09:43, sebb  wrote:
>>
>> On 20 April 2018 at 12:11,   wrote:
>>> Hi
>>>
>>> I have given some thought to the proposal by Sebb that replaces my proposal.
>>>
>>> There have been on/off talks over a long time about simplifying the 
>>> maintenance, common for the talks are the wish to only maintain a single 
>>> file, preferable json format.
>>
>> Why is a single file necessary?
>>
>>> The proposal from Sebb have a lot of good qualities, but the latest 
>>> suggestion is a file pr project combined with yaml files, this is far from 
>>> the original wish and something I cannot support.
>>
>> Why not?
> Because it is multiple files instead of 1 file.

Huh?
Unless you are updating multiple projects, it is only one file.

> You need to edit the .md, which eventually will lead to different 
> content/look&feel project files (with content I mean different classes of 
> content, like some will have related projects others will not even have the 
> field…also with .md it is possible to reorder the information).

How is that different from JSON data?
JSON does not have mandatory attributes, nor does it insist on a
particular order.
And what does the order matter?

>>
>>> I am also a bit concerned about having a bot running for something that 
>>> changes 3-4 times pr year, it seem like a waste of Infra resources.
>>
>> This same bot is used for lots of sites.
>>
>>> It is important that the maintenance can be carried out easily and it is 
>>> important that the look/feel of the site stays identical e.g. old urls must 
>>> remain available.
>>
>> Agreed.
>>
>>> Adding a struct in a json file secures easy maintenance, as in the original 
>>> proposal.
>>
>> I disagree that JSON is the way to go.
>>
>>> Please let us not complicate things.
>>
>> JSON is complicated to use with anything other than small amounts of
>> textual data.
> Not really, at least not from my pow, and after all I just converted all 
> projects to json, that should count for some experience.

As I wrote elsewhere, not all the information in the existing XML
files has been transferred.

It was when I started looking at how to do that with JSON that I
started to think that JSON is not the right format.

Have a look at how to transfer the additional information from some of
the following:

Abdera
AxKit
Beehive
Crimson
DeviceMap
Excalibur
HiveMind
iBatis
ECS
ORO
Regexp
Slide
Taglibs (this has a lot of info)
Muse
OJB
Shale
Whirr
Xang
XML
XMLBeans

Some of that info could perhaps be added to the description field.
But I don't think it's practical for everything.

And I don't think it's right to drop the information.

>>
>>> This started because I wanted to simplify my life and have grown into 
>>> something bigger.
>>
>>> Bigger might be better, but is it really needed, and are there somebody 
>>> willing to do our job (move retired project to the Attic) ?
>>
>> Personally, I would much rather create/edit a single YAML file per
>> project than a large slab of JSON.
> YAML would solve the problem of a single file, but for that you need to think 
> about how to online validate the file, before committing. As a personal 
> opinion I find YAML with its less restrictive format a lot more error prone.
>
>
> rgds
> Jan I.
>>
>>> rgds
>>> Jan I.
>

Re: Second proposal for new site maintenance.

[Jan Iversen]

> On 22 Apr 2018, at 11:27, sebb  wrote:
> 
> On 22 April 2018 at 09:51, Jan Iversen  > wrote:
>> 
>> 
>>> On 22 Apr 2018, at 09:43, sebb  wrote:
>>> 
>>> On 20 April 2018 at 12:11,   wrote:
 Hi
 
 I have given some thought to the proposal by Sebb that replaces my 
 proposal.
 
 There have been on/off talks over a long time about simplifying the 
 maintenance, common for the talks are the wish to only maintain a single 
 file, preferable json format.
>>> 
>>> Why is a single file necessary?
>>> 
 The proposal from Sebb have a lot of good qualities, but the latest 
 suggestion is a file pr project combined with yaml files, this is far from 
 the original wish and something I cannot support.
>>> 
>>> Why not?
>> Because it is multiple files instead of 1 file.
> 
> Huh?
> Unless you are updating multiple projects, it is only one file.
Correct, but it is a new file every time, and not the same file.

> 
>> You need to edit the .md, which eventually will lead to different 
>> content/look&feel project files (with content I mean different classes of 
>> content, like some will have related projects others will not even have the 
>> field…also with .md it is possible to reorder the information).
> 
> How is that different from JSON data?
Because with JSON data, each project file is generated, and thus guaranteed to 
have the same layout.

> JSON does not have mandatory attributes, nor does it insist on a
> particular order.
> And what does the order matter?
The order in the JSON file does not matter, but the layout of the project file 
matters, they should all be identical
> 
>>> 
 I am also a bit concerned about having a bot running for something that 
 changes 3-4 times pr year, it seem like a waste of Infra resources.
>>> 
>>> This same bot is used for lots of sites.
>>> 
 It is important that the maintenance can be carried out easily and it is 
 important that the look/feel of the site stays identical e.g. old urls 
 must remain available.
>>> 
>>> Agreed.
>>> 
 Adding a struct in a json file secures easy maintenance, as in the 
 original proposal.
>>> 
>>> I disagree that JSON is the way to go.
>>> 
 Please let us not complicate things.
>>> 
>>> JSON is complicated to use with anything other than small amounts of
>>> textual data.
>> Not really, at least not from my pow, and after all I just converted all 
>> projects to json, that should count for some experience.
> 
> As I wrote elsewhere, not all the information in the existing XML
> files has been transferred.
Well, then you do not talk about a missing feature, but an error in the update 
(which I already have mentioned earlier).

> 
> It was when I started looking at how to do that with JSON that I
> started to think that JSON is not the right format.
> 
> Have a look at how to transfer the additional information from some of
> the following:
> 
> Abdera
> AxKit
> Beehive
> Crimson
> DeviceMap
> Excalibur
> HiveMind
> iBatis
> ECS
> ORO
> Regexp
> Slide
> Taglibs (this has a lot of info)
> Muse
> OJB
> Shale
> Whirr
> Xang
> XML
> XMLBeans
> 
> Some of that info could perhaps be added to the description field.
> But I don't think it's practical for everything.
I politely have a different opinion
> 
> And I don't think it's right to drop the information.
We can agree on that, and that is solvable in both solutions.

rgds
Jan I.
> 
>>> 
 This started because I wanted to simplify my life and have grown into 
 something bigger.
>>> 
 Bigger might be better, but is it really needed, and are there somebody 
 willing to do our job (move retired project to the Attic) ?
>>> 
>>> Personally, I would much rather create/edit a single YAML file per
>>> project than a large slab of JSON.
>> YAML would solve the problem of a single file, but for that you need to 
>> think about how to online validate the file, before committing. As a 
>> personal opinion I find YAML with its less restrictive format a lot more 
>> error prone.
>> 
>> 
>> rgds
>> Jan I.
>>> 
 rgds
 Jan I.