Re: proposal: session server side variables

2016-12-29 10:32 GMT+01:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

>
>
> 2016-12-29 10:11 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:
>
>>
>> There is big difference - you concept missing any safe point. You have to
>>> specify same information more times.
>>>
>>
>> Not necessarily, and if so maybe twice. I'm ok to recognize that it is a
>> difference between both approaches, and an inconvenient of the one I'm
>> proposing. There also see inconvenients to the other design as well, so
>> there will not be any perfect solution, IMO. That is the point of
>> discussing.
>
>
>>
>> I am sorry, this discussion is in cycle - there is no sense to continue.
>>>
>>
>> If the only open option is to agree with your initial design, then
>> obviously this is not a path for reaching a consensus.
>>
>
> There are two concepts - both can be implemented, and used (can be used
> together). Both these concepts has some advantage and some disadvantages.
> It is hard to expect, so there is possible full agreement - because
> everybody has different preferences.
>
> I understand so for you can be your proposal more readable, but for me,
> your design of usage and security looks not well. It is acceptable without
> PRIVATE flags and similar flags. It is not designed be secure. (MySQL has
> nothing similar, I don't know if MSSQL has some, but probably not). Ok. We
> have different priorities. For you is not usual so in one session there can
> be more more times switch of secure context. It is usual for me, and for
> applications what I write.
>
>
>>
>> Could you put your ideal (final) design proposition on the wiki page?
>> That would avoid repeating the same cyclic arguments, they would be written
>> only once...
>
>
> yes, I'll do it.
>

But I'll remove some strange ideas. Why persistent variables?

Please, one argument. We have tables. What is wrong on tables?

Anything what will be persistent will have similar performance like tables.

Regards

Pavel

>
> Regards
>
> Pavel
>
>
>>
>>
>> --
>> Fabien.
>>
>
>