Maxim,
this don't seem a big architectural change for me, and I see no concerns. I
may be mistaken. And of course we should have a linkedin/twitter/facebook
user at some point.
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://dataved.ru/
+7 916 562 8095
Wicket have modules to auth via 3rd party services shouldn't be a problem
On Mon, Jun 3, 2013 at 9:48 PM, Alexei Fedotov alexei.fedo...@gmail.comwrote:
Maxim,
this don't seem a big architectural change for me, and I see no concerns. I
may be mistaken. And of course we should have a
Currently we get hash in flash client, then pass it to server.
I believe in later versions it should be changed to be handled by wicket
(3.1+)
On Jun 2, 2013 2:02 PM, seba.wag...@gmail.com seba.wag...@gmail.com
wrote:
Hi Maxim,
I will try to answer your points more detailed,
But just about
OK :)
I would vote for unifing hash, but this can be postponed :)
On Jun 2, 2013 3:26 PM, seba.wag...@gmail.com seba.wag...@gmail.com
wrote:
Yes we might transfer the hash from the client to the server.
But this is really not doing anything with the hash, its just proxying data
... for
I see, I think I have bit of an idea of what you try to do.
So actually when a user adds a new *contact* by adding for example an
external invitee to a meeting that he creates through the calendar, you
would add a new entry to the table *users* ?
Is that right ?
So there would be no more table
external invitee to a meeting that he creates through the calendar, you
would add a new entry to the table *users* ?
Is that right ?
Yes this was my idea :)
I believe user_contacts might be necessary if we would like to have
request contact feature (might be useful to see contact details
Hm,
yes I think it makes sense, the user contacts could be really a user record
instead of a record in the user_contacts table.
*Currently it is impossible, from my point of view, to create address book.*
Well you can simply write a native SQL query that maps those tables and
read the results
Hm,
the backup should be always backwards compatible. I would rather prefer to
really convert the old schema to the new one.
It might be possible to include in the XML file of the export a version
attribute.
Depending on what version the XML has you can either do the one style of
import (3.0 and
Hi Maxim,
I am not sure if I do understand that proposal.
In what sense does this affect what we currently have? From what I
understood this is only one more additional column in the user table that
does indicate how this user was created.
But for instance users that enter a conference room via
