properties.ston or properties.json ?

[mumez]

Cypress spec says that "Properties of repository, package and class are stored in file named 'properties.ston'". However, implementations other than STIG use 'properties.json', so it causes interchangeability problems. (For example, I could not load a FileTree-derived project tree from STIG).

If saved properties are just JSON objects (the spec says "for portability it must be restricted to the JSON subset", I think just using 'properties.json' is simpler.

If we should use 'properties.ston' from now on, I think some implementation guideline for migration is needed.

For example:

• The loader first check 'properties.ston', and if it does not exist, it reads 'properties.json' for fallback.
• The saver should write 'properties.ston', but existing 'properties.json' should be kept untouched for older implementations"
• Or just provide batch conversion tool (changing filenames to 'properties.json' to 'properties.ston').

Personally I like ston format, but are there any specific usecase for storing complex objects in properties file? If not, I think just sticking to 'properties.json' can avoid migration problems.

[dalehenrich]

Musashi,

The sort answer is that .ston should be used moving forward.

What is described on the wiki is our latest thinking snd moving forward we want to use STON ... if is compatible with JSON and will give us the flexibility to include serialized objects in the future ...

There is no need to preserve any of the artifacts in the repository (like old .json files).. readers should be able to determine what format the repository is in by looking at the various property files.

We are dealing with code repositories here and we have to be able to continue to read old repository formats while being allowed to move forward as our needs evolve and even as an individual dialect's needs evolve.

So STIG will create artifacts for VW packages that do not have an analog in Pharo packages and that is okay as long as those artifacts are in separate files/directories ...

The primary directive is to allow the sharing of the source code files and common class properties between dialects.

The current thinking is that each dialect would have it's own branch (Xtream and FileTree are examples) but perhaps the only truly shared artifacts will be the .st files and basic file structure ... It's not a perfect world, but I think it is the best we can hope for:)

The spec is still evolving a bit (see Issue #17 and Issue #19)...

Hope this hslps clarify things.

Dale

[mumez]

OK. I understood the direction. I've written a simple FileMan script for batch solution.

But I also hope FileTree provides somewhat transparent compatibility for the existing projects. I think many users (including me) are already using FileTree. And running the batch to each project would be tiresome.

[dalehenrich]

Masashi,

I do intend to upgrade FileTree to support the new formt ... I've just not had the time, but I need to squeeze some time in soon ... now that there is additional interest, I'll bump the priority:)

Dale

----- Original Message -----
| From: "Masashi Umezawa" [email protected]
| To: "CampSmalltalk/Cypress" [email protected]
| Cc: "Dale Henrichs" [email protected]
| Sent: Thursday, May 2, 2013 8:22:37 AM
| Subject: Re: [Cypress] properties.ston or properties.json ? (#20)
|
| OK. I understood the direction. I've written a simple FileMan
| script for batch solution.
|
| But I also hope FileTree provides somewhat transparent compatibility for the
| existing projects. I think many users (including me) are already using
| FileTree. And running the batch to each project would be tiresome.
|
| ---
| Reply to this email directly or view it on GitHub:
| #20 (comment)
|