When contributing it is associated to licence so I just find the actual model a bit weak.

I don't think that this is the case anymore. Pharo itself (and more and more pharo projects) are moving to git, so the Author string is not really used outside of the given image --- the author is based on git config (author) and github account (comiter). In respect to code authorship, you can even sign your commits with git (I guess this could be an option in Iceberg at some future point in time).

Could we imagine a user id instead ? I think the most common "user id" tends to be email, as it is the most unambiguous id tied to a specific user (and easy to verify for ownership). But ensuring that someone else cannot use my "id" can be counter-productive in some scenarios -- e.g. when moving projects from sthub to github I had to "pretend" that I am someone else when creating the commits so the authorship is properly preserved for all contributors.

Another question is if an image may be used by several people ? I don't know the precise semantics, but when you move image the Author (the class where this is stored) should be reset. So if you send your image to someone else they should be asked to provide the name.

having an external personal system that could be plugged upon each new image startup. I would very much like this, as right now I have to store all passwords and credentials in plaintext in the image (settings) loaded from a startup script that I have publicly on github... ( https://github.com/peteruhnak/pharo-scripts/blob/master/config/6.0/iceberg-c... ) But iirc iceberg can now use credential managers? (not sure what is the state)

Cheers, Peter On Thu, Dec 28, 2017 at 10:23 AM, Cédrick Béler <cdrick65@gmail.com> wrote:

Of course this can be enough but this could be more objectified. A string cannot be called a model to me.

For now nothing prevents from having somebody use the id of someone else. When contributing it is associated to licence so I just find the actual model a bit weak.

Then, additional functionalities could be built like storing other informations, certificates, having an external personal system that could be plugged upon each new image startup.

But yes the actual solution is ok. Was just thinking loud as I try to develop personal information system, this is something that could be interesting for my use case ;-)

Cheers,

Cedrick

...

Le 27 déc. 2017 à 21:44, Offray Vladimir Luna Cárdenas < offray.luna@mutabit.com> a écrit :

Hi,

I wonder why first and last name are not good enough. I have found the model clear and privacy aware. Such image id is complemented with remote credentials in remote repositories (SmalltalkHub, GitHub, etc) and I deploy distinct images for distinct projects or releases (which is now easier with PharoLauncher), so I fail to see other use cases.

Cheers,

Offray

...

On 27/12/17 08:05, Cédrick Béler wrote: Hi all,

For now, it is asked (by convention) a string containing our first name and last name (when code is submitted). Just wandering if you could have a better representation of a user of a Pharo image.

Could we imagine a user id instead ? That shouldn’t be heavy to deal with and eventually one could add more functionalities (one being the authentification to a pharo based application).

The difficulty is to find a proper universal user id. I would have used something that encode date and place of birth in the id but it suffers some privacy related issues. Any ideas ? Another question is if an image may be used by several people ? To me allowing one user is ok for a developer image but it might be interesting to switch user spaces if it’s for a pharo application ?

Cheers,

Cédrick