> On 22 Apr 2018, at 11:27, sebb <seb...@gmail.com> wrote: > > On 22 April 2018 at 09:51, Jan Iversen <jancasacon...@gmail.com > <mailto:jancasacon...@gmail.com>> wrote: >> >> >>> On 22 Apr 2018, at 09:43, sebb <seb...@gmail.com> wrote: >>> >>> On 20 April 2018 at 12:11, <j...@apache.org> 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.
