Dates white ==> Nov2005 Pink ==> discussion1 Blue ==> discussion3 purple ==> discussion4 green ==> versions purpledar1==> mail1 yellow ==> downloaded files brown1=>mail3 |
Discussions
==> Specifications |
Was
this implemented? Yes or NO Date of Implementation |
What
was implemented : exactly same or different from specifications |
What
do the testing show? |
12
july 2004 |
* user choose his own syntax system in forums, bold and italic, his own system of smileys. pas fait ~~~> a faire pour les themes de wiki * wiki ~ system of forums: invitations systemfor rights to write and rights to read for all pages of a given folder ( ~ for my forums system there is an invitations system for each forum) * ~ personal pages (like wiki but the right to right is reserved for one person) rien * how to generate the web pages. ~~~~> wikis : rien fait * let users make their own web pages easily. |
|||
27
july 2004 |
http://spoirier.lautre.net/work/
|
|||
18
august 2004 |
http://sylvain.belprog.com/efforum/ |
|||
24
august 2004 |
-- Topic selection (like Windows Schemes) ----- CSS ----- pictures *templates |
|||
24
august 2004 |
-- Topic selection (like Windows Schemes) ----- CSS ----- pictures * templates? |
|||
24
august 2004 |
* -- Topic selection (like Windows Schemes) ----- CSS ----- pictures * user can choose his own color scheme for the forums. * parameters of the configuration to include ? * templates separate code and html and to make more clean HTML |
|||
25
august 2004 |
* personal web pages : ~~~~> pas fait |
|||
25
august 2004 |
2. User Configuration, personal web page. Personal page, where the user can write all he wants User's info display configuration (First Name, Last Name, icq, ip, signature, etc) |
|||
26
august 2004 |
* Personal page ( user can write all he wants) |
|||
Mar 2
novembre 2004 |
* Dating ~~~~> pas vraiment fini * Personal WebPages ~~~~> rien fait |
|||
Sam 6
novembre 2004 |
============================================================================= #001: uploaded photos are suitable or not (like: size, resolution, etc). ============================================================================= ~~~> systeme de rencontre permet de mettre une seule photo - au lieu d'enregistrer la photo : url pour photos sur meme site ~~~> plus tard meme photo pour plusieurs usages???? annonce de rencontre confidentielle ou pas vraiment? : ============================================================================= > personal web page, first choose an existing pseudo of yours, or create a new one just for this purpose. ==> Then you will make a web page attached to this pseudo. ~~~~~~~~~~~~~~~~~~~ #004: So, how many diffirent independent dating accounts and web pages can have a single user and a single pseudo? ============================================================================= ============================================================================= #005: As I see, the first web page should contain all the information about a person which was entered at the 1st step and nothing more, and the second (optional) web page should contain any additional information the user wants to be read by the selected (or S+) by him people. Am I right? ============================================================================= |
|||
Dim 7 novembre 2004 |
======================================================================== #001: Are there any criteria according to which the system would decide whether the recently uploaded photos are suitable or not (like: size, resolution, etc). In what way (where) can they be set? ======================================================================= Why do you speak about "recently uploaded photos" ? If user is uploading a photo specially for this, yes it would be good to check limits in size: that width and height are inside a range of values, and that the size in kb is no heigher than a given value. So, display these values of the uploaded photo together with the ranges of acceptable values. This range of acceptable value would be universal constants, so they cannot be set to different values. But since with the personal web pages part that Frozen Team is doing, user can also upload photos there, it would be good to "unify" these upload possibilities, so that user can for dating, instead of uploading a photo once more, select one of his existing photos. Or maybe give another URL somewhere else so that a photo can be displayed without upload. Anyway, I think of giving the possibility to other users to say if they think a photo is not suitable. ======================================================================= #002: Would you please describe more definite, what pages should the system contain? Is it to have any kind of the main page? What items are there to be in the user menu? Where are the links to start a dating account to be placed? I mean, should I create an index.php or an inclusion (like dating_login.inc) first? ======================================================================= With the user documentation there would be a part of doc about dating. In the user configuration page there would be a link: "Open a dating account". This would add a new link "Dating" at the top menu. Clicking on this link would access a dating menu following more or less the list of points I described in my text of dating user documentation, something like : -create/edit profile - creat/set personal web page - activate profile (reception of matches):yes/no - send profile! - review new matches (how many are there) - reviewing old matches and their personal pages (now many, how many new)... I don't understand your question " should I create an index.php or an inclusion (like dating_login.inc) first" ======================================================================= > The helping comments for each item (profile or photo) forms a public > forum attached to it. ~~~~~~~~~~~~~~~~~~~ #003: Please, describe it more definitely. ======================================================================= Finally, don't do this part as I got another idea to solve the problem more simply: let the possibility to activate profile before sending it, and the possibility to warn another user that the photo has a problem wy a simple click. ======================================================================= > As for any other personal web page, you must first choose an > existing pseudo of yours, or create a new one just for this purpose. > Then you will make a web page attached to this pseudo. ~~~~~~~~~~~~~~~~~~~ #004: So, how many diffirent independent dating accounts and web pages can have a single user and a single pseudo? ======================================================================= A single user can have only one dating account, linking to one or two web pages. But he can have different web pages for each pseudo. ======================================================================= #005: As I see, the first web page should contain all the information about a person which was entered at the 1st step and nothing more, and the second (optional) web page should contain any additional information the user wants to be read by the selected (or S+) by him people. Am I right? ======================================================================== No. Both web pages are like any personal web pages, freely composed by the user.I think one's parameters could be accessed from the matches list; it is not a personal web page, just an info on profile that need not access the other's site but is just extracted from the info that was received for matching computation.One's search criteria, though first received together with parameters for matching computation, should never be accessible by the other user (so, be deleted from the receiver's site just after this computation ?). ============================================================================= > To spead up the reviewing of your matches, you have the option to > let them appear on two windows alternatively, so that every one is > being loaded during the time when you are reviewing the other: after > you reviewed one page and click to validate your selection, this > page goes to the background for loading the next matches while you > can review the other page that has already been loaded. ~~~~~~~~~~~~~~~~~~~ #006: And is there to exist a third (actually, first) page with the list of viewed users? ======================================================================== No. What viewed users ? I was speaking about the two pages to be displayed simultaneously. Once a screen was viewed and eventually some matches were selected, after click all matches from that screen change statuses and therefore go to different lists.Of course, if one wants after that to view again matches seen just before, one can click elsewhere to review the trash or other lists of selected matches. ======================================================================== > From 4) or 4bis), those you select receive from you the status S > (while U/N of T/N becomes S/U so your profile appears to them), so > that they go to 4ter) or 5). ~~~~~~~~~~~~~~~~~~~ #007: As I understand, people have "unlisted" (N) status for me, if they do not match to my search criteria. But if some user that is "unlisted" for me selects me, he anyway becomes shown in my lists. Is it right? ======================================================================= Yes: unlisted is a very abstract status that concretely means: not received in the database of your server (but your profile is in the database of his server). Then, this has the effect of him sending his profile to you. ======================================================================= #008: How, more concretely, the user is to be able to connect his dating profile(s) with his pseudos? ======================================================================= He does not connect his dating profile with his pseudos. Only his web page is connected to his pseudos (each page has an author). And the profile is connected to the web page as a link in the old matches list after both users have selected each other. |
|||
7 nov 2004 |
=============================================================================> #008: How, more concretely, the user is to be able to connect his > dating profile(s) with his pseudos? > =============================================================================> More precisely: of course at the home site the profile is connected to the user. Then what is sent with the profile to other site is the profile id. I wondered about the possibility to have a specifically dating pseudo that would accept invitation to forums only by old matches. Not sure it is really needed (instead, user can blacklist by hand).Also, to decide about web pages whether the reading rights would be automatically reserved to matches with the corresponding status (but anyway user can choose to use for dating a pseudo that allows invitation by anybody, and web pages that anybody can access). |
|||
Sam 13 novembre 2004 |
000001: Registration ================================ Actions: 1.The user enters his common parameters only once to create the dating account. 2.The user chooses criteria to search for other users.3.The user enters any other information describing him. 4.Upload a photo. 5.Ask for advice. 6.Help advising others. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1,2. There is some set of searching criteria. The user is first asked to enter his corresponding parameters (1) and then asked to choose criteria by which the system should search for matches (2). User’s parameters (common trades of character, weight/height, date of birth, some personal preferences and so on) cannot be changed later. Criteria of search can be changed at any time. ===========-> Of course the birth date should not change but there are some parameters that may honestly change, like wheight, hobbies... It would be recommanded to the user that he changes nothing but it's not an obligation. Changing search criteria is no less problematic than changing parameters, from a technical viewpoint (both are parts of the same file, and modifications rises the question of whether the matching with past profiles should be recomputed or not. ========== 4. There can be some constant limitations (file size, dimensions). The system should check them before accepting the picture. 5.A. Is the user is not sure whether the picture is suitable, he may check “ask for advices” so that others would see click links “I think the picture is not suitable” and “I think the picture is suitable” and leave messages. Then the statistics of opinions is displayed to the user and he is notified when too many people think the picture is bad. Incoming messages are also shown. ===== -> Ok. I suggested that we would drop this part as another solution would be to allow for profile activation before sending, then including the possibility to do warnings in this real context, but the best may be to implement both ideas at the same time. ===== 5.B. If the user is not sure whether the information he entered (3) is suitable, he can also turn on the option “ask for advices”. Everything is the same. 6. The user can also give advices to others if he wants. There should be an item “Help advising others” where the user would be able to choose to view either men’s or women’s photos or men’s or women’s profiles. It can also help to decide if his profile is well done and to study the usual mistakes. ===== -> OK. ============================================================================= #000002: Creating a personal Web page.================================ Actions: 1.Create a new Web page and associate with to some pseudo. 1.1.Choose whether it will be a public or a private page. 1.2.Upload more pictures/videos. 1.3.Edit text information. 2.Edit existing Web pages. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -> That is Frozen Team's part ===== For the dating account to start functioning, the user is to have at least one public page. Every pseudo must have a public page to have a private page. ====== -> No. Having one page is sufficient. One can have a private page without having a public page. Then one would select in dating which page to use. If it is a public page, then it will stay so. If it is a private page, then the reading rights will be automatically modified by the dating program depending on status of matches. ===== Pages can contain any pictures/videos (no limitations) and any other text information the user wants to make known. Public pages can be viewed by everybody. Private ones can be viewed only by those people who have corresponding rights (see below). This step can be passed and done after the 3rd step is done, but this step is necessary for the dating account to be activated. =========================================================================== -> I would say: this step is necessary for the dating system to run until the end. But I call "activating the dating account" the fact of receiving new matches, which is what the 3rd step is handling. ============================================================================= #000003: Review and select new matches (“U” folder).================================ 1.Choose parameters to display in the list of matches. 2.View the list of matches. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Here the user chooses the columns of the table of matches to be displayed. There must be some constant initial settings. 2. The list of matches the system found suitable for you. The user chooses (checks) the people who he thinks would maybe be interesting for him. There are following statuses of matches:unlisted (N) unreviewed (U) trashed (T) selected (S) selected+ (S+) ========== -> I said the real status of a match is not one such symbol but a pair of such symbols: (status A gives to B, status B gives to A). ====== Unlisted: those matches which do not correspond to the search criteria. ==== -> I called this way the situation of being possibly oneself on the other's server but not having the other's file in one's server because he did not select us. OK, another situation is when the computation gives a negative result. I think, keeping them would be interesting only in the case one modifies his profile and wants to review matches agreeing with the new profile without disturbing anybody else. But it forces the system to keeping a copy of all profiles received. Is it heavy if there are millions ? ====== All other matches have an “U” status from the very beginning. After this step, the user checks matches he thinks he might be interested in page by page, so that the listed matches become either trashed (“T”) or selected (“S”). The user views each of the listed matches in the following way: two pop-ups are shown. One of them displays information about the currently viewed match (the user views it and decides whether to select or not), the he finally clicks “next”. Then another pop-up becomes active. The idea is to save time: the first pop-up is loaded while the second one is viewed and vise versa. When the user clicks next, another pop-up containing already loaded information about the next match becomes active. ============================================================================ -> Yes, but with a difference: each pop-up displays information not about one match but about 10 or more matches, one per line (the exact number can be chosen in the configuration together with the list of parameters to show). To select a profile, check the box on the left. Next answers in the next message. What about the hosting? |
|||
Jeu 18
novembre 2004 |
=========================================================== > Unlisted: those matches which do not correspond to the search criteria. > ==== utilisateur enregistre --> envoie son profil recus par tous les hostes qui ont un systeme de rencontre. recu par le serveur de l'autre est-ce que les parametres son ok? si non ==> supprime donnees si oui ==> ajoute profil sur la liste quand le calcul montre que ca correspond: il le guarde pour ses propres utilisateurs sans avertir les envoyeurs. >> I called this way the situation of being possibly oneself on the other's >> server but not having the other's file in one's server because he did not >> select us. > ====== ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~> listes : statuts de couples =========================================================== > #000006: List of twofold selected matches.================================ > In this folder are listed the matches which have been chosen as S or S+ by > the user and have also chose the user as S or S+. > ===== >> Yes, and every match there also links (aside the web page(s)) to the >> creation or viewing of a forum if it is not done; and I am not sure >> whether to list to the same screen those where a forum has started or not. > ===== ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #000002: What forum are you talking about? =========================================================== |
|||
Jeu 18 novembre 2004 |
============================================================================= #000001: Registration ================================ Actions: 1. The user enters his common parameters only once to create the dating account. 2. The user chooses criteria to search for other users. 3. The user enters any other information describing him. 4. Upload a photo. 5. Ask for advice. 6. Help advising others. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1,2. There is some set of searching criteria. The user is first asked to enter his corresponding parameters (1) and then asked to choose criteria by which the system should search for matches (2). The user has an ability to change his parameters, but he is recommended not to do it. He can also change his search criteria. From a technical point of view, changing either personal parameters or criteria of search is rather problematic as these actions cause all matches to be checked once more and each time it takes a lot of time for the system to re-check the matches. So the user must be reminded to be very accurate while filling the fields. 4. There can be some constant limitations (file size, dimensions). The system should check them before accepting the picture. 5.A. If the user is not sure whether the picture is suitable, he may check "ask for advices" option and let others to advise him. In this case, others see links "I think the picture is/isn't ok" and click on them and leave messages explaining why, if they wish. Then the user sees the statistics and sent messages. So before activating the account, the user waits for others' opinions. But if he doesn't want to wait but regrets, he may upload a photo and check "allow to do warnings" option. It allows him to end the registration and activate an account. In this case, everybody viewing his photo sees the link "I think it's bad" and, clicking on it, can also send a message explaining why. In this case the user can change a photo but everybody who has already viewed it and moved the user to trash do not view it again after the photo changes. The plus point of this case is in saving the time but on the other hand, the user looses some matches. By the way, the user can choose the system to activate his account automatically and stop asking for advice if enough people think that the picture is good (in the 1st case). In the 2nd case, the user can also choose the system to stop allowing people to do warnings when many people do not click the link "I think the picture's bad", and to make a reminding alert when too many people do. 5.B. Everything is the same with the description the user entered. 6. The user can also give advices to others if he wants. There should be an item "Help advising others" where the user would be able to choose to view either men's or women's photos or men's or women's profiles. It can also help to decide if his profile is well done and to study the usual mistakes. ============================================================================= ============================================================================= #000002: Creating a personal Web page. ================================ Actions: 1. Changing the statuses of the pages. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Web pages can be public or private. Every pseudo can have no pages. In doesn't forbid the account to be activated but it forbids the user to contact with his matches. His account is blocked until the personal page is created. Pseudos can also have one public page. It can be viewed by everybody. The pseudo can have as many private pages as he wants. They can be viewed only by those people who have received the "S" or "S+" status from the user (read below about the statuses). The user can also edit permissions by hand. For example, he can disallow somebody selected by him to view some of his private pages or otherwise allow some not already selected people to view ones. ============================================================================= ============================================================================= #000003: Review and select new matches ("U" folder). ================================ 1. Choose parameters to display in the list of matches. 2. View the list of matches. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Here the user chooses the columns of the table of matches to be displayed. There must be some constant initial settings. 2. The list of matches the system found suitable for you. The user chooses (checks) the people who he thinks would maybe be interesting for him. Technically, in each pair of people {x,y} that the automatic selection had found as a possible match, there are two parameters: the status of x for y (that y chose to give to x), and the status of y for x. The following statuses exist: - unlisted (N) - unreviewed (U) - trashed (T) - selected (S) - selected+ (S+) Unlisted: those matches which do not correspond to the search criteria. All other matches have an "U" status from the very beginning. After this step, the user checks matches he thinks he might be interested in page by page, so that the listed matches become either trashed ("T") or selected ("S"). The user views each of the listed matches in the following way: two pop-ups are shown. One of them displays information about some number of the currently viewed matches (the user views them and decides whether to select or not), the he finally clicks "next". Then another pop-up becomes active. The idea is to save time: the first pop-up is loaded while the second one is viewed and vise versa. When the user clicks next, another pop-up containing already loaded information about the next matches becomes active. The number of shown matches can be changed together with selecting the parameters to show. The default value is 10. ============================================================================= ============================================================================= #000004: Statuses of matches. ================================ When the user first sends his profile, he doesn't access yet to the others' profiles so they are unlisted (N) for him, but he becomes unreviewed (U) for all those the computers find he matches with. New matches, contains without visible distinction, except that in fact, it is displayed in the following order of priority: U/S+; U/S; U/N; U/U* For every page of the list of the new matches the user views, they will all change their status for either S or T according to whether the user selects them or not, when he clicks to review his next page of matches. * We will implement the U/U status later. ============================================================================= ============================================================================= #000005: Select more closely. ================================ In this folder are listed the matches with statuses S/U and S+/U. It means that the user has already chosen these people with S or S+, but they haven't yet. Well, the user may either move someone to trash or update S status for S+ to possibly help starting contacting this match a bit earlier. This list can also display the matches which are blocked because of not having the personal web page. ============================================================================= ============================================================================= #000006: List of twofold selected matches. ================================ In this folder are listed the matches which have been chosen as S or S+ by the user and have also chose the user as S or S+. ============================================================================= ============================================================================= #000007: Viewing the info pages of matches. ================================ The user must be able to do the following actions: 1. View the public web page. 2. Invite the match to the own private web pages. 3. View the user's second (private) page, if he is invited to. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ By the way, the user is to be able to change matches' statuses everywhere they appear between T, S, and S+. ============================================================================= |
|||
Ven 19 novembre 2004 |
=============================================================================> #000001: Registration ================================ Actions: 1. The user enters his common parameters only once to create the dating account. 2. The user chooses criteria to search for other users. 3. The user enters any other information describing him. 4. Upload a photo. 5. Ask for advice. 6. Help advising others. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> 1,2. There is some set of searching criteria. The user is first asked to enter his corresponding parameters (1) and then asked to choose criteria by which the system should search for matches (2). The user has an ability to change his parameters, but he is recommended not to do it. He can also change his search criteria. From a technical point of view, changing either personal parameters or criteria of search is rather problematic as these actions cause all matches to be checked once more and each time it takes a lot of time for the system to re-check the matches. So the user must be reminded to be very accurate while filling the fields. 4. There can be some constant limitations (file size, dimensions). The system should check them before accepting the picture. 5.A. If the user is not sure whether the picture is suitable, he may check "ask for advices" option and let others to advise him. In this case, others see links "I think the picture is/isn't ok" and click on them and leave messages explaining why, if they wish. Then the user sees the statistics and sent messages. So before activating the account, the user waits for others' opinions. But if he doesn't want to wait but regrets, he may upload a photo and check "allow to do warnings" option. It allows him to end the registration and activate an account. In this case, everybody viewing his photo sees the link "I think it's bad" and, clicking on it, can also send a message explaining why. In this case the user can change a photo but everybody who has already viewed it and moved the user to trash do not view it again after the photo changes. The plus point of this case is in saving the time but on the other hand, the user looses some matches. By the way, the user can choose the system to activate his account automatically and stop asking for advice if enough people think that the picture is good (in the 1st case). I would think it is better to never let the activation of account be automatic. In the 2nd case, the user can also choose the system to stop allowing people to do warnings when many people do not click the link "I think the picture's bad" Why not *always* allow people to do warnings ? Just to avoid spam ? Well, it's like any spam: informing the root about it will put spammers in trouble.As I said, the warnings should form a public forum associated to the profile because it is not for private correspondance, and if someone makes a remark, the next one can say: " I agree with x's remark and would add that...". The link to this public forum appears only in the new matches list and (cf below) whereas the list of selected matches links only to the private forum of the match. I think more and more of the necessity to have a special folder for matches in intermediate statuses:- In question because one hesitates or because the photo is not clear - Selected but yet unreviewed by the other - Selected but blocked by the absence of web page of one or the other. |
|||
Ven 19 novembre 2004 |
=============================================================================> #000002: Creating a personal Web page. > ================================ ~~~~> pas fait > Actions: > 1. Changing the statuses of the pages. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> Web pages can be public or private. Every pseudo can have no pages. In > doesn't forbid the account to be activated but it forbids the user to > contact with his matches. His account is blocked until the personal > page is created. Pseudos can also have one public page. It can be > viewed by everybody. The pseudo can have as many private pages as he > wants. They can be viewed only by those people who have received the > "S" or "S+" status from the user (read below about the statuses). The > user can also edit permissions by hand. For example, he can disallow > somebody selected by him to view some of his private pages or otherwise > allow some not already selected people to view ones. > ============================================================================= Pseudos can have as many public pages as they want. In general, there is a system to handle rights to view private pages by editing rights by the author and by invitation except the invitations will be disabled in the case of dating, and the modification by status of matches will run instead. ============================================================================= > #000003: Review and select new matches ("U" folder). > ================================ > 1. Choose parameters to display in the list of matches. > 2. View the list of matches. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> 1. Here the user chooses the columns of the table of matches to be > displayed. There must be some constant initial settings. 2. The list of > matches the system found suitable for you. The user chooses (checks) > the people who he thinks would maybe be interesting for him. > Technically, in each pair of people {x,y} that the automatic selection > had found as a possible match, there are two parameters: the status of > x for y (that y chose to give to x), and the status of y for x. The > following statuses exist: > - unlisted (N) > - unreviewed (U) > - trashed (T) > - selected (S) > - selected+ (S+) > Unlisted: those matches which do not correspond to the search criteria. So I told you in a recent message what I meant, different from this, but I wonder: as there are many people per server, among 2 users x and x' of a server considering match with user y of another server, one can have y "unlisted" for x but unreviewed or selected for older user x'. Until eventually y selects x. In this case I wonder: should y's server send again y's profile for x although it is already stored for x' ?Anyway, before y selected x, though y's profile was in x's server it was not handled in relation with the account of x, more precisely the computation of possible match between x and y did not happen in x's server because it is done by y's server. |
|||
Mer 24 novembre 2004 |
=============================================================================> #000001: Registration > ================================ > - Place of living (some constant cases are given; only one can be > chosen, of course) > - Purpose of meeting (some constant cases are given; any number > is possible to be chosen) It looks like you still did not read the web page I told you describing the parameters & criteria !!!The place of living is not a good parameter as it can change it time. > 4. There can be some constant limitations (file size, dimensions). The > system should check them before accepting the picture. > 5.A. If the user is not sure whether the picture is suitable, he may > check “ask for advices” option and let others to advise him. In this > case, a new public forum is created. Others see links “I want to give > an advice” and click on them and leave messages explaining why, if they > wish. Then the user sees sent messages. Others can leave messages because they have access to this public forum. > So before activating the account, the user waits for others’ opinions. > But if he doesn’t want to wait but regrets, he may upload a photo and > check “allow to do warnings” option. It allows him to end the > registration and activate an account. In this case, everybody viewing > his photo sees the link “I think it’s bad” I would put the expression "Do warning" instead. > and, clicking on it, can access the attached public forum, therefore > also send a message explaining why. In this case the user can change a > photo but everybody who has already viewed it and moved the user to > trash do not view it again after the photo changes. The plus point of > this case is in saving the time but on the other hand, the user looses > some matches. > By the way, the user can choose the system to turn off the “allow to do > warnings” option when many people pass (do not click) the link “I think > the picture’s bad”, and to make a reminding alert when too many people > do. > 5.B. Everything is the same with the description the user entered. Well, I did not react to this yet but I'm not sure that doing warnings for parameters can make any sense. Parameters are something personal. The only people that can eventually detect something wrong in parameters are people that personnally know this person. I suggest to not develop anything for this in the short term.Or if you have a different view on this problem, ============================================================================= > #000002: Creating a personal Web page. > ================================ > Actions: > 1. Changing the statuses of the pages. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> Web pages can be public or private. Every pseudo can have no pages. In > doesn’t forbid the account to be activated but it forbids the user to > contact with his matches. His account is blocked until the personal > page is created. I would not say "his account" but only "the next steps of the dating operations" are blocked |
|||
Mer 24 novembre 2004 |
=============================================================================> #000001: Registration > ================================ > Actions: > 1. The user enters his common parameters only once to create the > dating account. > 2. The user chooses criteria to search for other users. > 3. The user enters any other information describing him. > 4. Upload a photo. > 5. Ask for advice. > 6. Help advising others. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> 1,2. There is some set of searching criteria. The user is first asked > to enter his corresponding parameters (1) and then asked to choose > criteria by which the system should search for matches (2). The user > has an ability to change his parameters, but he is recommended not to > do it. He can also change his search criteria. From a technical point > of view, changing either personal parameters or criteria of search is > rather problematic as these actions cause all matches to be checked > once more and each time it takes a lot of time for the system to > re-check the matches. But the user can choose not to do the > re-checking but to apply the new data to the newly received files > only. Anyway, the user must be reminded to be very accurate while > filling the fields. More precisely, to take one's time to do it, check > it and check it again (re-edit it) before activating the file, and even > more before sending it. > There should be next necessary fields: > - Date of birth (three integer values) > - Sex (M/F) > - Place of living (some constant cases are given; only one can be > chosen, of course) > - Purpose of meeting (some constant cases are given; any number > is possible to be chosen) > 4. There can be some constant limitations (file size, dimensions). The > system should check them before accepting the picture. > 5.A. If the user is not sure whether the picture is suitable, he may > check “ask for advices” option and let others to advise him. In this > case, a new public forum is created. Others see links “I want to give > an advice” and click on them and leave messages explaining why, if they > wish. Then the user sees sent messages. > So before activating the account, the user waits for others’ opinions. > But if he doesn’t want to wait but regrets, he may upload a photo and > check “allow to do warnings” option. It allows him to end the > registration and activate an account. In this case, everybody viewing > his photo sees the link “I think it’s bad” and, clicking on it, can > also send a message explaining why. In this case the user can change a > photo but everybody who has already viewed it and moved the user to > trash do not view it again after the photo changes. The plus point of > this case is in saving the time but on the other hand, the user looses > some matches. > By the way, the user can choose the system to turn off the “allow to do > warnings” option when many people pass (do not click) the link “I think > the picture’s bad”, and to make a reminding alert when too many people > do. > 5.B. Everything is the same with the description the user entered. 6. > The user can also give advices to others if he wants. There should be > an item “Help advising others” where the user would be able to > choose to view either men’s or women’s photos or men’s or women’s > profiles. It can also help to decide if his profile is well done and to > study the usual mistakes. > =============================================================================> > =============================================================================> #000002: Creating a personal Web page. > ================================ > Actions: > 1. Changing the statuses of the pages. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> Web pages can be public or private. Every pseudo can have no pages. In > doesn’t forbid the account to be activated but it forbids the user to > contact with his matches. His account is blocked until the personal > page is created. Pseudos can also have as many public pages as they > want. They can be viewed by everybody. Rights for private pages can be > edited, but it is the other programmer’s work. > =============================================================================> > =============================================================================> #000003: Review and select new matches (“U” folder). > ================================ > 1. Choose parameters to display in the list of matches. > 2. View the list of matches. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> 1. Here the user chooses the columns of the table of matches to be > displayed. There must be some constant initial settings. > 2. The list of matches the system found suitable for you. The user > chooses (checks) the people who he thinks would maybe be interesting > for him. > Technically, in each pair of people {x,y} that the automatic selection > had found as a possible match, there are two parameters: the status of > x for y (that y chose to give to x), and the status of y for x. > The following statuses exist: > - unlisted (N) > - unreviewed (U) > - trashed (T) > - selected (S) > - selected+ (S+) > Unlisted: those matches which do not correspond to the search criteria. > All other matches have an “U” status from the very beginning. > After this step, the user checks matches he thinks he might be > interested in page by page, so that the listed matches become either > trashed (“T”) or selected (“S”). > The user views each of the listed matches in the following way: two > pop-ups are shown. One of them displays information about some number > of the currently viewed matches (the user views them and decides > whether to select or not), the he finally clicks “next”. Then another > pop-up becomes active. The idea is to save time: the first pop-up is > loaded while the second one is viewed and vise versa. When the user > clicks next, another pop-up containing already loaded information > about the next matches becomes active. The number of shown matches can > be changed together with selecting the parameters to show. The default > value is 10. > ============================================================================ One detail: in each pop-up, the number of (u) remaining matches is displayed. In case the user is planning to stop reviewing before all U matches are viewed, he can click a checkbox saying "Stop displaying new matches now" before clicking on the "Next" button. So the other pop-up appears for its last review but this one is closed after sending selection data, and then the other pop-up closes also after its selection. =============================================================================> #000006: List of twofold selected matches. > ================================ > In this folder are listed the matches which have been chosen as S or S+ > by the user and have also chose the user as S or S+. Every twofold > selected match, when appears, causes a new private forum to be created. > > ============================================================================ Yes, or more precisely: first, a link to a private forum that need not "exist" as long as it has never been used, but that will be created at first click (or by the validation of the first message ?). If simultaneously both people have this link to create a private forum, one clicks to create the forum at his home server, which sends the signal to the other's server so that when the other clicks to create the forum he does not create another one but is redirected to the forum just created. > =============================================================================> #000007: Viewing the info pages of matches. > ================================ > The user must be able to do the following actions: > 1. View the public web page. > 2. Invite the match to the own private web pages. > 3. View the user’s second (private) page, if he is invited to. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Oh yes but this is concerns the personal web pages part and info page on pseudo independently of dating, and since Frozen Team is working on it let's wait and see the result of their work. |
|||
Mer 24
novembre 2004 |
============================================================================= #000001: Registration ================================ Actions: 1. The user enters his common parameters only once to create the dating account. 2. The user chooses criteria to search for other users. 3. The user enters any other information describing him. 4. Upload a photo. 5. Ask for advice. 6. Help advising others. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1,2. There is some set of searching criteria. The user is first asked to enter his corresponding parameters (1) and then asked to choose criteria by which the system should search for matches (2). The user has an ability to change his parameters, but he is recommended not to do it. He can also change his search criteria. From a technical point of view, changing either personal parameters or criteria of search is rather problematic as these actions cause all matches to be checked once more and each time it takes a lot of time for the system to re-check the matches. But the user can choose not to do the re-checking but to apply the new data to the newly received files only. Anyway, the user must be reminded to be very accurate while filling the fields. More precisely, to take one's time to do it, check it and check it again (re-edit it) before activating the file, and even more before sending it. There should be next necessary fields: - Date of birth (three integer values) - Sex (M/F) - Place of living (some constant cases are given; only one can be chosen, of course) - Purpose of meeting (some constant cases are given; any number is possible to be chosen) 4. There can be some constant limitations (file size, dimensions). The system should check them before accepting the picture. 5.A. If the user is not sure whether the picture is suitable, he may check “ask for advices” option and let others to advise him. In this case, a new public forum is created. Others see links “I want to give an advice” and click on them and leave messages explaining why, if they wish. Then the user sees sent messages. So before activating the account, the user waits for others’ opinions. But if he doesn’t want to wait but regrets, he may upload a photo and check “allow to do warnings” option. It allows him to end the registration and activate an account. In this case, everybody viewing his photo sees the link “I think it’s bad” and, clicking on it, can also send a message explaining why. In this case the user can change a photo but everybody who has already viewed it and moved the user to trash do not view it again after the photo changes. The plus point of this case is in saving the time but on the other hand, the user looses some matches. By the way, the user can choose the system to turn off the “allow to do warnings” option when many people pass (do not click) the link “I think the picture’s bad”, and to make a reminding alert when too many people do. 5.B. Everything is the same with the description the user entered. 6. The user can also give advices to others if he wants. There should be an item “Help advising others” where the user would be able to choose to view either men’s or women’s photos or men’s or women’s profiles. It can also help to decide if his profile is well done and to study the usual mistakes. ============================================================================= ============================================================================= #000002: Creating a personal Web page. ================================ Actions: 1. Changing the statuses of the pages. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Web pages can be public or private. Every pseudo can have no pages. In doesn’t forbid the account to be activated but it forbids the user to contact with his matches. His account is blocked until the personal page is created. Pseudos can also have as many public pages as they want. They can be viewed by everybody. Rights for private pages can be edited, but it is the other programmer’s work. ============================================================================= ============================================================================= #000003: Review and select new matches (“U” folder). ================================ 1. Choose parameters to display in the list of matches. 2. View the list of matches. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Here the user chooses the columns of the table of matches to be displayed. There must be some constant initial settings. 2. The list of matches the system found suitable for you. The user chooses (checks) the people who he thinks would maybe be interesting for him. Technically, in each pair of people {x,y} that the automatic selection had found as a possible match, there are two parameters: the status of x for y (that y chose to give to x), and the status of y for x. The following statuses exist: - unlisted (N) - unreviewed (U) - trashed (T) - selected (S) - selected+ (S+) Unlisted: those matches which do not correspond to the search criteria. All other matches have an “U” status from the very beginning. After this step, the user checks matches he thinks he might be interested in page by page, so that the listed matches become either trashed (“T”) or selected (“S”). The user views each of the listed matches in the following way: two pop-ups are shown. One of them displays information about some number of the currently viewed matches (the user views them and decides whether to select or not), the he finally clicks “next”. Then another pop-up becomes active. The idea is to save time: the first pop-up is loaded while the second one is viewed and vise versa. When the user clicks next, another pop-up containing already loaded information about the next matches becomes active. The number of shown matches can be changed together with selecting the parameters to show. The default value is 10. ============================================================================= ============================================================================= #000004: Statuses of matches. ================================ When the user first sends his profile, he doesn’t access yet to the others' profiles so they are unlisted (N) for him, but he becomes unreviewed (U) for all those the computers find he matches with. New matches, contains without visible distinction, except that in fact, it is displayed in the following order of priority: U/S+; U/S; U/N; U/U* For every page of the list of the new matches the user views, they will all change their status for either S or T according to whether the user selects them or not, when he clicks to review his next page of matches. * We will implement the U/U status later. ============================================================================= ============================================================================= #000005: Select more closely. ================================ In this folder are listed the matches with statuses S/U and S+/U. It means that the user has already chosen these people with S or S+, but they haven’t yet. Well, the user may either move someone to trash or update S status for S+ to possibly help starting contacting this match a bit earlier. This list can also display the matches which are blocked because of not having the personal web page. ============================================================================= ============================================================================= #000006: List of twofold selected matches. ================================ In this folder are listed the matches which have been chosen as S or S+ by the user and have also chose the user as S or S+. Every twofold selected match, when appears, causes a new private forum to be created. ============================================================================= ============================================================================= #000007: Viewing the info pages of matches. ================================ The user must be able to do the following actions: 1. View the public web page. 2. Invite the match to the own private web pages. 3. View the user’s second (private) page, if he is invited to. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ By the way, the user is to be able to change matches’ statuses everywhere they appear between T, S, and S+. ============================================================================= |
|||
Dim 12 décembre 2004 |
- conversation starts in
the private forum of a match, then one trashes the other, then it is an unsubscription from the forum; the other can still access the forum in one of his folder but, I don't know how exactly it should be: cannot write anymore in the forum ? - one's parameters can be known by the other but not one's criteria, so what to do with parts of the file that are neither parameters nor criteria, like the part : "looking for" (giving numbers of penalties for each possibility) : I think the computer should compute for each possibility the sum of both numbers of penalties, then select the possibilities where this number is no more than 10 plus the minimum over all possibilities, and display for each user the penalty numbers for each of these possibilities. |
|||
Mar 28 décembre 2004 |
- GLS+forum - dating system. 2) What is the unlisted status? I meant that it did not enter yet one's database (whereas the inverse match can be present in the other's database, that one's database knows this absence from the first one). 4) There was a preposition to create public forum instead of messages about bad foto/details. Will this forums have a direct connection with forum system (or will be separate?). Also where this forum will be displayed?(Among other forums???) Who will be owner(1st admin) of that forum? - possibility of public forums that do not appear in the global list of public forums, but that people can however subscribe to and add to a folder.The owner will be the author of the profile. He will be automatically subscribed to this forum, so it will appear in his main box when there are new messages (uh, did you make the possibility to subscribe to public forums ?). For others (until they subscribe), they can find it only by following the link "comment others'photos" in the dating system, aside the photo (or clicking on the photo). 5) The same questions like in the 4), but about Private forum for messaging of 2 people that selected one another. Where this private forum will be displayed(what box?) For first admin, you can let the first one who writes a message as first admin and let this forum be hosted at his site.I think it would be good to add a folder specific for dating that will automatically contain these private forums once created (and one's public forum above for his profile).Also in the dating part, the list of S/S and more matches should display the photos together with the links to the private forums or creation of these forums (so that you must first go there for starting conversation, then you continue it either by this list or by the dating folder) 6) Common question. One person is registered in the system and has many pseudos. He creates "Dating Account". Is it possible to create just One dating account? Or some dating accounts? (I think this string is not correct) Yes, only one. How we should connect Dating with Accounts and Pseudos? (You know that Personal Web Pages and forums have an attachment with pseudos ) I said that dating is connected with the pseudo author of the dating Personal Web Page but this pseudo is not sent together with profile (only an abstract dating id (with host of course) is sent with profile), but pseudo is sent only by the S status. Uh, for the public forum of the photo I wonder. Maybe use another pseudo ? or let the dating id play the role of pseudo ? 7) What about administrating of the rights for the "private web pages". 8) Will be "trashed" users have an access to the "public web pages" Trashed users have not the link (they have no more the match in their lists), except if they had the chance to bookmark it by other means of course... 9) Some letters ago you said about "files", "activating the files". Activating the file means that the "new matches" list is created and one starts receiving matches there. In other words, that when it is active, any time a profile will be received from the outside (from others that "send" it) it will be compared to this file to possibly enter this matches list. Previously received profiles B will not be compared to this newly active one A, because they will wait for A to be sent to B to be reviewed by B first. 10) >> Why not *always* allow people to do warnings ? Just to avoid spam ? >> Well, it's like any spam: informing the root about it will put >> spammers in trouble...... > We think that if the user is sure that all information is correct then > why we should clutter up with a code. > Probably, he will not look at > it. So we need to inform the user that there is new > messages. This forum to his main box ! 11) What is the sense of creating some "public pages" per pseudo? I don't remember to have asked such a thing: no obligation to create public pages for every pseudo, but every page created must have an author (a pseudo).Or do you ask about the "info page" on a pseudo, with the comment : when there will be the trust system, info on the level of trust to this pseudo or complaints will appear. 12) > handling web pages is other programmers' part. > What features they will handle? Will they create "rights editing" ? > Would be nice to see Personal Web Pages' DataBase structure. I saw their demo (it is at forum.frozenteam.sobig.biz) - system of rights editing > One part from the messaging: >> So I told you in a recent message what I meant, different from this, >> but I wonder: as there are many people per server, among 2 users x and >> x' of a server considering match with user y of another server, one >> can have y "unlisted" for x but unreviewed or selected for older user >> x'. Until eventually y selects x. In this case I wonder: should y's >> server send again y's profile for x although it is already stored for >> x' >> ?Anyway, before y selected x, though y's profile was in x's server it >> was not handled in relation with the account of x, more precisely the >> computation of possible match between x and y did not happen in x's >> server because it is done by y's server. - specialists in the field of DataBase planning, cross-platform systems etc: the traffic between servers. - centralise the distribution of sent profiles to reduce traffic, so that those who send, send only once, and those who receive, receive many at the same time from different hosts. But if they receive several, they will be busy testing their matches at once, which may make the server busy for some seconds, unless of course this process is affected a low priority... |
|||
Mar 28 décembre 2004 |
-errors in uniting GLS+forum - dating system. 2) What is the unlisted status? 4) There was a preposition to create public forum instead of messages about bad foto/details. Will this forums have a direct connection with forum system (or will be separate?). Also where this forum will be displayed?(Among other forums???) Who will be owner(1st admin) of that forum? 5) The same questions like in the 4), but about Private forum for messaging of 2 people that selected one another. Where this private forum will be displayed(what box?) 6) Common question. One person is registered in the system and has many pseudos. He creates "Dating Account". Is it possible to create just One dating account? Or some dating accounts? (I think this string is not correct) How we should connect Dating with Accounts and Pseudos? (You know that Personal Web Pages and forums have an attachment with pseudos ) 7) What about administrating of the rights for the "private web pages". 8) Will be "trashed" users have an access to the "public web pages" 9) Some letters ago you said about "files", "activating the files". Please explain more precisely. 10) > Why not *always* allow people to do warnings ? Just to avoid spam ? Well, > it's like any spam: informing the root about it will put spammers in > trouble...... - need to inform the user that there is new messages. 11) What is the sense of creating some "public pages" per pseudo? 12) handling web pages is other programmers' part. What features they will handle? Will they create "rights editing" ? Would be nice to see Personal Web Pages' DataBase structure. One part from the messaging: - there are many people per server, among 2 users x and x' of a > server considering match with user y of another server, one can have y > "unlisted" for x but unreviewed or selected for older user x'. Until > eventually y selects x. In this case I wonder: should y's server send > again y's profile for x although it is already stored for x' > ?Anyway, before y selected x, though y's profile was in x's server it was > not handled in relation with the account of x, more precisely the > computation of possible match between x and y did not happen in x's server > because it is done by y's server. - cross-platform systems etc. -traffic between servers. - multihost testing. |
|||
Sam 8 janvier 2005 |
- forums system: - About Edit forum rights: the invitation table should not be editable, even by admins.There should be * permissions by invitation, that can only increase; someone's inviter is the last one who increased the right* limitations, that can be edited by admin; no limitation can be put to an admin.The status of admin can be lost only by resign and if there exists another admin. The right that one can really use and invite other people to have, is defined to be the smaller between permission and limitation. Well, all this scheme may not be always perfect but it is already good and we will be satisfied with it in the short term. - About folders: I already wrote you at least twice (please find the messages) that the presentation should be revised, to not fill the screen with "move to folder" buttons: have checkboxes to select forums, then specify which operation to do with them at the bottom of the list. Do not display the name of creator there but the name of members (whose who wrote or may write) except oneself if there are not too many, else only amins. - About languages: I told you to revise the list of possible operations on language files. - GLS is now but it should contain in its database the list of peer servers that you will use in your dating system. |
|||
Mer 12 janvier 2005 |
=============================================================================> #000001: Registration ================================ Actions: 1. The user enters his common parameters only once to create the dating account. 2. The user chooses criteria to search for other users. 3. The user enters any other information describing him. 4. Upload a photo. 5. Advices. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> 1,2. There is some set of searching criteria. The user is first asked to enter his corresponding parameters (1) and then asked to choose criteria by which the system should search for matches (2). The user has an ability to change his parameters, but he is recommended not to do it. He can also change his search criteria. From a technical point of view, changing either personal parameters or criteria of search is rather problematic as these actions cause all matches to be checked once more and each time it takes a lot of time for the system to re-check the matches. But the user can choose not to do the re-checking but to apply the new data to the newly received files only. Anyway, the user must be reminded to be very accurate while filling the fields. More precisely, to take one's time to do it, check it and check it again (re-edit it) before activating the file, and even more before sending it. There should be next necessary fields: - Date of birth (three integer values) - Sex (M/F) Ok for this, but: - Place of living (some constant cases are given; only one can be chosen, of course) NO!!!!!! HOW MANY TIMES SHOULD I REPEAT YOU THE SPECIFICATIONS FOR PARAMETERS AND SEARCH CRITERIA ARE THOSE DESCRIBED ON PART 1 OF http://spoirier.lautre.net/forum/dating.htm!!!!!! - Purpose of meeting (some constant cases are given; any number is possible to be chosen) NO AGAIN: SEE THE ABOVE LINK !!!!!! 4. There can be some constant limitations (file size, dimensions). The system should check them before accepting the picture. 5.A. When an account is created, a new forum "Photo advices" is automatically created and placed into "Dating forums" folder (a child of "Public forums") No because unlike usual folders, this shows photos; and this "folder" should not be accessed from the list of public forums but from the list of dating operations.And the "dating forums" folder is normally a list of private forums, plus only oneself's photo's public forum. (more later) |
|||
Mer 12
janvier 2005 |
In this case the user can
change a photo but everybody who has already viewed it and moved the user to trash do not view it again after the photo changes. The plus point of this case is in saving the time but on the other hand, the user looses some matches. Now I think there should be another status "don't know" where it is not selected but not trashed either and it can be reviewed again in the special folder for blocked matches and S/U status. > 5.B. Everything is the > same with the description the user entered. A public forum called > "Common advices" is created. I told you I'm not sure this has a point. Can you see it ? > Actions: > 1. Changing the statuses of the pages. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> Web pages can be public or private. Every pseudo can have no pages. In > doesn't forbid the account to be activated but it forbids the user to > contact with his matches. The next steps of the dating operations are > blocked until the personal page is created. Pseudos can also have as > many public pages as they want. They can be viewed by everybody. Rights > for private pages can be edited, but it is the other programmer's work. > It has to be said that the dating account is strongly connected with > the pseudo. So the user can have no more dating accounts than the > number of pseudos he has. No, the user has only one dating account, related to one pseudo. |
|||
Mer 12 janvier 2005 |
> 1. Common things: > a. Integration to forums > b. Developing DB > 2. Registration: > a. Entering account information page > b. Managing photos page The upload of photos PWP part. Here you just need to include one URL of the photo in the file and this URL will be entered as such in the "img src" of the matches lists.> c. Creating special public forums page > 3. Integrating Personal Web Pages. This step can be passed if > necessary. 4. DB developing: > a. Creating dating folders tables > b. Creating matches statuses tables (a. and b. repeat the same information ? in different tables) > c. Developing search system Yes it's a big part, computation of totals of penalties for each of both people and common penalties. > 5. "U" folder page > 6. "T", "S", "S+" folders pages No: one folder "T", one folder "special or blocked or waiting (S/U) ", one folder "S or S+" > 7. Twofold selected matches: > a. Managing matches page > b. Creating private forums > 8. Solving some security problems > 9. Testing, fixing bugs > 10. Integrating with GLS, solving multi-host problems ok ------- |
|||
Mer 12
janvier 2005 |
============================================================================= #000001: Registration ================================ Actions: 1. The user enters his common parameters only once to create the dating account. 2. The user chooses criteria to search for other users. 3. The user enters any other information describing him. 4. Upload a photo. 5. Advices. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1,2. There is some set of searching criteria. The user is first asked to enter his corresponding parameters (1) and then asked to choose criteria by which the system should search for matches (2). The user has an ability to change his parameters, but he is recommended not to do it. He can also change his search criteria. From a technical point of view, changing either personal parameters or criteria of search is rather problematic as these actions cause all matches to be checked once more and each time it takes a lot of time for the system to re-check the matches. But the user can choose not to do the re-checking but to apply the new data to the newly received files only. Anyway, the user must be reminded to be very accurate while filling the fields. More precisely, to take one's time to do it, check it and check it again (re-edit it) before activating the file, and even more before sending it. There should be next necessary fields: - Date of birth (three integer values) - Sex (M/F) - Place of living (some constant cases are given; only one can be chosen, of course) - Purpose of meeting (some constant cases are given; any number is possible to be chosen) 4. There can be some constant limitations (file size, dimensions). The system should check them before accepting the picture. 5.A. When an account is created, a new forum "Photo advices" is automatically created and placed into "Dating forums" folder (a child of "Public forums"). Others start to see the link "Give an advice" and click on them and leave messages explaining why, if they wish. The only admin of this forum will be The User. It should be said that this forum is some kind of "private" in the sense that it is stored only in the user's "Dating forums" folder, noone else sees it in his folders. If many people think the photo is bad, they can leave advices. In this case the user can change a photo but everybody who has already viewed it and moved the user to trash do not view it again after the photo changes. The plus point of this case is in saving the time but on the other hand, the user looses some matches. 5.B. Everything is the same with the description the user entered. A public forum called "Common advices" is created. ============================================================================= ============================================================================= #000002: Creating a personal Web page. ================================ Actions: 1. Changing the statuses of the pages. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Web pages can be public or private. Every pseudo can have no pages. In doesn't forbid the account to be activated but it forbids the user to contact with his matches. The next steps of the dating operations are blocked until the personal page is created. Pseudos can also have as many public pages as they want. They can be viewed by everybody. Rights for private pages can be edited, but it is the other programmer's work. It has to be said that the dating account is strongly connected with the pseudo. So the user can have no more dating accounts than the number of pseudos he has. ============================================================================= ============================================================================= #000003: Review and select new matches ("U" folder). ================================ 1. Choose parameters to display in the list of matches. 2. View the list of matches. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Here the user chooses the columns of the table of matches to be displayed. There must be some constant initial settings. 2. The list of matches the system found suitable for you. The user chooses (checks) the people who he thinks would maybe be interesting for him. Technically, in each pair of people {x,y} that the automatic selection had found as a possible match, there are two parameters: the status of x for y (that y chose to give to x), and the status of y for x. The following statuses exist: - unlisted (N) - unreviewed (U) - trashed (T) - selected (S) - selected+ (S+) Unlisted: those matches which do not correspond to the search criteria. All other matches have an "U" status from the very beginning. After this step, the user checks matches he thinks he might be interested in page by page, so that the listed matches become either trashed ("T") or selected ("S"). The user views each of the listed matches in the following way: two pop-ups are shown. One of them displays information about some number of the currently viewed matches (the user views them and decides whether to select or not), the he finally clicks "next". Then another pop-up becomes active. The idea is to save time: the first pop-up is loaded while the second one is viewed and vise versa. When the user clicks next, another pop-up containing already loaded information about the next matches becomes active. The number of shown matches can be changed together with selecting the parameters to show. The default value is 10. ============================================================================= ============================================================================= #000004: Statuses of matches. ================================ When the user first sends his profile, he doesn't access yet to the others' profiles so they are unlisted (N) for him, but he becomes unreviewed (U) for all those the computers find he matches with. New matches, contains without visible distinction, except that in fact, it is displayed in the following order of priority: U/S+; U/S; U/N; U/U* For every page of the list of the new matches the user views, they will all change their status for either S or T according to whether the user selects them or not, when he clicks to review his next page of matches. * We will implement the U/U status later. ============================================================================= ============================================================================= #000005: Select more closely. ================================ In this folder are listed the matches with statuses S/U and S+/U. It means that the user has already chosen these people with S or S+, but they haven't yet. Well, the user may either move someone to trash or update S status for S+ to possibly help starting contacting this match a bit earlier. This list can also display the matches which are blocked because of not having the personal web page. ============================================================================= ============================================================================= #000006: List of twofold selected matches. ================================ In this folder are listed the matches which have been chosen as S or S+ by the user and have also chose the user as S or S+. Every twofold selected match, when appears, causes a new private forum to be created. ============================================================================= ============================================================================= #000007: Viewing the info pages of matches. ================================ The user must be able to do the following actions: 1. View the public web page. 2. Invite the match to the own private web pages. 3. View the user's second (private) page, if he is invited to. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ By the way, the user is to be able to change matches' statuses everywhere they appear between T, S, and S+. ============================================================================= ------- Time Shedule.doc Work scheduling. 1. Common things: a. Integration to forums b. Developing DB 2. Registration: a. Entering account information page b. Managing photos page c. Creating special public forums page 3. Integrating Personal Web Pages. This step can be passed if necessary. 4. DB developing: a. Creating dating folders tables b. Creating matches statuses tables c. Developing search system 5. "U" folder page 6. "T", "S", "S+" folders pages 7. Twofold selected matches: a. Managing matches page b. Creating private forums 8. Solving some security problems 9. Testing, fixing bugs 10. Integrating with GLS, solving multi-host problems |
|||
Jeu 13 janvier 2005 |
=============================================================================> #000001: Registration > ================================ > Actions: > 1. The user enters his common parameters only once to create the > dating account. 2. The user chooses criteria to search for other > users. > 3. The user enters any other information describing him. > 4. Upload a photo. > 5. Advices. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 1,2. There is some set of searching criteria. The user is first asked > to enter his corresponding parameters (1) and then asked to choose > criteria by which the system should search for matches (2). The user > has an ability to change his parameters, but he is recommended not to > do it. He can also change his search criteria. From a technical point > of view, changing either personal parameters or criteria of search is > rather problematic as these actions cause all matches to be checked > once more and each time it takes a lot of time for the system to > re-check the matches. But the user can choose not to do the re-checking > but to apply the new data to the newly received files only. Anyway, the > user must be reminded to be very accurate while filling the fields. > More precisely, to take one's time to do it, check it and check it > again (re-edit it) before activating the file, and even more before > sending it. There should be next necessary fields: > - Date of birth (three integer values) > - Sex (M/F) > - Place of living (some constant cases are given; only one can be > chosen, of course) - Purpose of meeting (some constant cases are > given; any number is possible to be chosen) 4. There can be some > constant limitations (file size, dimensions). The system should check > them before accepting the picture. 5.A. When an account is created, a > new forum "Photo advices" is automatically created and placed into > "Dating forums" folder (a child of "Public forums"). Others start to > see the link "Give an advice" and click on them and leave messages > explaining why, if they wish. The only admin of this forum will be The > User. It should be said that this forum is some kind of "private" in > the sense that it is stored only in the user's "Dating forums" folder, > noone else sees it in his folders. If many people think the photo is > bad, they can leave advices. > In this case the user can change a photo but everybody who has already > viewed it and moved the user to trash do not view it again after the > photo changes. The plus point of this case is in saving the time but on > the other hand, the user looses some matches. 5.B. Everything is the > same with the description the user entered. A public forum called > "Common advices" is created. > =============================================================================> > =============================================================================> #000002: Creating a personal Web page. > ================================ > Actions: > 1. Changing the statuses of the pages. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Web pages can be public or private. Every pseudo can have no pages. In > doesn't forbid the account to be activated but it forbids the user to > contact with his matches. The next steps of the dating operations are > blocked until the personal page is created. Pseudos can also have as > many public pages as they want. They can be viewed by everybody. Rights > for private pages can be edited, but it is the other programmer's work. > It has to be said that the dating account is strongly connected with > the pseudo. So the user can have no more dating accounts than the > number of pseudos he has. > =============================================================================> > =============================================================================> #000003: Review and select new matches ("U" folder). > ================================ > 1. Choose parameters to display in the list of matches. > 2. View the list of matches. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> 1. Here the user chooses the columns of the table of matches to be > displayed. There must be some constant initial settings. 2. The list of > matches the system found suitable for you. The user chooses (checks) > the people who he thinks would maybe be interesting for him. > Technically, in each pair of people {x,y} that the automatic selection > had found as a possible match, there are two parameters: the status of > x for y (that y chose to give to x), and the status of y for x. The > following statuses exist: > - unlisted (N) > - unreviewed (U) > - trashed (T) > - selected (S) > - selected+ (S+) And as I said, another status "special" between "unreviewed" and "selected", for the case when the photo is not clear and one wants to wait for it to become clear, for example. Passing from "unreviewed" to "special" makes no effect to the other user. It is just a way of delaying the decision to select or trash. So let us call it D for "delayed". > Unlisted: those matches which do not correspond to the search criteria. No: when it does not correspond, there is no status in my sense. Just nonexistence in the matches table (after checking the match, and seeing that it does not correspond, the server does not include it in the user's table).Status "unlisted" is only half a status: If "B's status for A is N", it is no status for A as it means A sent file to B but A's server does not know of the existence of B, it is only a status registered in B's server that knows that B is not known to A. > All other matches have an "U" status from the very beginning. > After this step, the user checks matches he thinks he might be > interested in page by page, so that the listed matches become either > trashed ("T") or selected ("S"). or delayed. > The user views each of the listed > matches in the following way: No, only the unreviewed list, to be quick. The other lists (trash, delayed, selected) are not meant to be reviewed so quickly, so the trick of 2 popups is not useful. > two pop-ups are shown. One of them > displays information about some number of the currently viewed matches > (the user views them and decides whether to select or not), the he > finally clicks "next". Then another pop-up becomes active. The idea is > to save time: the first pop-up is loaded while the second one is viewed > and vise versa. When the user clicks next, another pop-up containing > already loaded information about the next matches becomes active. The > number of shown matches can be changed together with selecting the > parameters to show. The default value is 10. > =============================================================================> > =============================================================================> #000004: Statuses of matches. > ================================ > When the user first sends his profile, he doesn't access yet to the > others' profiles so they are unlisted (N) for him, but he becomes > unreviewed (U) for all those the computers find he matches with. New > matches, contains without visible distinction, except that in fact, it > is displayed in the following order of priority: U/S+; U/S; U/N; U/U* > For every page of the list of the new matches the user views, they will > all change their status for either S or T or D > according to whether the user > selects them or not, when he clicks to review his next page of matches. > * We will implement the U/U status later. > =============================================================================> > =============================================================================> #000005: Select more closely. > ================================ > In this folder are listed the matches with statuses S/U and S+/U. and D/anything and those blocked by absence of PWP. > It > means that the user has already chosen these people with S or S+, but > they haven't yet. Well, the user may either move someone to trash or > update S status for S+ to possibly help starting contacting this match > a bit earlier. This list can also display the matches which are blocked > because of not having the personal web page. > =============================================================================> > =============================================================================> #000006: List of twofold selected matches. > ================================ > In this folder are listed the matches which have been chosen as S or S+ > by the user and have also chose the user as S or S+. Every twofold > selected match, when appears, causes a new private forum to be created. > =============================================================================> > =============================================================================> #000007: Viewing the info pages of matches. > ================================ > The user must be able to do the following actions: > 1. View the public web page. Only from the list of twofold selected matches > 2. Invite the match to the own private web pages. You mean the second one ? This is no explicit operation. The only thing is to choose between S and S+. The status S+ means to give access to the second PWP if exists, else it just means "I love you". > 3. View the user's second (private) page, if he is invited to. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > By the way, the user is to be able to change matches' statuses > everywhere they appear between T, S, and S+. > ============================================================================= - forums to arrange access rights, presentations of folders and folders of forums hosted elsewhere through GLS (the trick of function for translations is less urgent). |
|||
Dim 16 janvier 2005 |
============================================================= #000001: A> Are you ready to learn the other's language (check: 0 or 1 or 2)? A> This would add this quantity to the quality of conversation in a A> language where the other's skill is better than yours, but not A> exceeding the other's skill. A> Example: if two people A and B have respective skills 2 and 3 for a A> given language, and both put "2" for "ready to learn the other's A> language", then their quality of conversation in this language is 3 A> because B cannot teach A to get a better skill than the level 3 he A> already has. What if the user puts "1" for "ready to learn other's language"? How should the system work in this case? ============================================================= ============================================================= #000002: A> Smoker: s= A> 1) No A> 2) A little but I can stop A> 3) A little A> 4) Yes A> Requirement: how many points of penalties for possible values of A> the of the other's s'>s (while zero for the lower s') What if a persons wants to find definitely a smoker? ============================================================= ============================================================= #000003: A> 1) Geographical criteria: make a table with columns: A> Region | badness as a place for first meeting | would have an A> income there if a long-term living (yes/ a little or perhaps /no) | A> badness if other has | a little | won't have an income What if a person considers the place is OK for first meeting but is bad for long-term living? ============================================================= ============================================================= #000004: A> If the person A registered before the person B, then we have the A> following history of matchings between A and B: A> B's status in A's list / A's status in B's list A> A> New1 ...... Not listed Why "Not listed" except for "New1"? When B registers, why doesn't he see A as a match? What's the difference between "old1" and "old2" ("new1" and "new2")? ============================================================= |
|||
Lun 17 janvier 2005 |
============================================================= #000001: A> Are you ready to learn the other's language (check: 0 or 1 or 2)? A> This would add this quantity to the quality of conversation in a A> language where the other's skill is better than yours, but not A> exceeding the other's skill. > A> Example: if two people A and B have respective skills 2 and 3 for a > A> given language, and both put "2" for "ready to learn the other's A> > language", then their quality of conversation in this language is 3 A> > because B cannot teach A to get a better skill than the level 3 he A> > already has. > What if the user puts "1" for "ready to learn other's language"? How > should the system work in this case? > ============================================================= If A puts 1 and B puts 0 then the result is 3. If A puts 0 and B puts 1 then the result is 2. In general the formula is min(max(A's skill,min(B's skill,A's skill+A's readiness)),same exchanging A and B). > > ============================================================= > #000002: > A> Smoker: s= > A> 1) No > A> 2) A little but I can stop > A> 3) A little > A> 4) Yes > A> Requirement: how many points of penalties for possible values of A> > the of the other's s'>s (while zero for the lower s') > What if a persons wants to find definitely a smoker? > ============================================================= Makes no sense as such. Nobody is bothered by someome not smoking. But if someone is smoking, he may be outselected by someone not smoking.However I'm not sure that this formula I wrote is the best one. I'll tell you next time. Or do you have another suggestion on this point ?I have the example of a man who does not like smoke but his wife smokes but she only smokes outside so he is not bothered.We could consider putting penalties to people who do not tolerate smoke. > ============================================================= > #000003: > A> 1) Geographical criteria: make a table with columns: > A> Region | badness as a place for first meeting | would have an > A> income there if a long-term living (yes/ a little or perhaps /no) | > A> badness if other has | a little | won't have an income > What if a person considers the place is OK for first meeting but is bad > for long-term living? > ============================================================= These questions are independent. A common number of penalties is computed for first meeting, minimum over all places; another one is computed for long term living, minimum over all places, that can be at a different place. > ============================================================= > #000004: > A> If the person A registered before the person B, then we have the A> > following history of matchings between A and B: > A> B's status in A's list / A's status in B's list > A> > A> New1 ...... Not listed > > Why "Not listed" except for "New1"? When B registers, why doesn't he > see A as a match? When B sends his file, A can receive it in his matches, and unless he selects it, B never sees it. > What's the difference between "old1" and "old2" ("new1" and "new2")?\ |
|||
Lun 17 janvier 2005 |
- have folders containing forums hosted elsewhere ?t important use of GLS in the forums system. What has now been made is another way: having access to the full functionality of an account at the remote host. It can be interesting as a way to create pseudos at another host, but it is not fundamental.So we can keep it as an option, but not as a general way of working. What is really needed is give an access to a private forum at a remote host without any other special functionality (not another contacts list,...) I'm wondering about what host should display the info page of a user. I think it is the home site of oneself, to keep the possibility to display the list of forums we have with that remote pseudo, with any of one's pseudos.This obliges the comments to be sent between hosts (the home site requests the comments, gets them and displays them). I don't need you code until all that will be done. Thank you. |
|||
Mer 19
janvier 2005 |
>> ============================================================= >> #000004: >> A> If the person A registered before the person B, then we have the A> >> following history of matchings between A and B: >> A> B's status in A's list / A's status in B's list >> A> >> A> New1 ...... Not listed >> >> Why "Not listed" except for "New1"? When B registers, why doesn't he >> see A as a match? A> When B sends his file, A can receive it in his matches, and unless he A> selects it, B never sees it. So, when the user B registers he receives no files immediately but starts receiving files of those who registers after him. Meanwhile, when his account activates all the existing users matching him receive his file. If somebody of them (like A) selects B, B also receives his (A's) file. Is that right? >> What's the difference between "old1" and "old2" ("new1" and "new2")?\ A> Forget about this part. It was the first draft before I developed all what A> we already discussed (status...). Thus, we leave all we already discussed (status...) adding calculating badnesses. Performing search, do we need to store values of badnesses in the DB for, for example, showing lists of matches already sorted to users in future or can we forget this value? |
|||
Mer 19 janvier 2005 |
- "Edit forum rights" part: is it reserved for the admin ? Is it the same as the invitations table that some can view even if they are not admin except that they cannot change it ? - In public forums, there should be the possibility for an admin to invite another admin to have admin right.And as I said, you should take the system of "edit forum rights" from public forums to apply to private forums, to deny rights to which someone was invited, so that for every user there will be both an invitation by someone, and a possible deniance. - have folders contain forums hosted elsewhere ? - webmail and PWP. |
|||
Ven 21 janvier 2005 |
In public forums, there should be the possibility for an admin to invite another admin to have admin right. And as I said, you should take the system of "edit forum rights" from public forums to apply to private forums, to deny rights to which someone was invited, so that for every user there will be both an invitation by someone, and a possible deniance. > > OK. > > A> Do you think you can soon manage to have folders containing forums > hosted A> elsewhere ? It is what I consider as the most important use > of GLS in the A> forums system. > > To let the system access forums hosted elsewhere I need to have > libraries which would perform sending/receiving custom queries between > different hosts of the system. As I understand, this part belongs to > development of GLS. Is that right? > A> What has now been made is another way: having access to the full A> > functionality of an account at the remote host. > > Do you mean that GLS doesn't support contacting remote hosts? unification of GLS+forum : bookmark goes to a forums site it makes a whole account there. What I had in mind is to lead only to a particular forum, without any registration in a users' database except the invitations table of the forum. - It can be interesting as a way to create pseudos at another host, but it is not fundamental. |
|||
Mer 26 janvier 2005 |
H forum.frozenteam.sobig.biz forum2.frozenteam.sobig.biz = PWP |
|||
Lun 31
janvier 2005 |
This is an updated TZ for the dating system. We've got one more question: >>============================================================================= >>#000006: Viewing the info pages of matches. >>================================ >>The user must be able to do the following actions: >>1. View the public web pages of twofold selected matches, >>2. Invite the match to the own private web pages. > You mean the second one ? This is no explicit operation. The only > thing is to choose between S and S+. The status S+ means to give > access to the second PWP if exists, else it just means "I love you". Q: What if the user has several private web pages and wants some ppl to access not all of them but only some? Q: Can the user invite somebody selected (but not selected+) to his private page? |
|||
Lun 31
janvier 2005 |
============================================================================= #000001: Registration ================================ Actions: 1. Choose a pseudo. 2. The user enters his parameters and search criteria (badnesses). 3. The user enters any other information describing him. 4. Upload a photo. 5. Advices. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. The user chooses a pseudo under which to create a dating account. The user can have an only dating account. In future he won't have possibility to change this pseudo. Either, he won't have possibility to remove this pseudo unless the dating account is removed. 2. The selection of possible partner will happen by a system of negative points, called penalties. For each possible situation concerning the parameters of the other person, the user will affect a number of penalties from 0 to 40. The computer will consider a person as a possible match so that each can review the other's profile, if the following three conditions are satisfied: - His/her total number of penalties in the user's criteria is lower than 40, - The user's total number of penalties in his/her criteria is lower than 40, - The sum of these two numbers and of the common badness penalties is lower than 70. Therefore, for each question, the user gives the number 0 to the best possibility in his view, and 40 to what he wants to exclude. First, here are the criteria of selection of one by the other that should not exceed 40. - Languages: for each possible language the user is asked to enter the skill in the language: 0: not speaking 1: something 2: a little 3: manage well 4: good 5: very good/native The user defines the badness to each possible quality of conversation (gives a number of penalties for each of the six possible qualities of conversation). This must be a decreasing series of numbers, as a poor quality of conversation (0) has a bigger badness than a good one (5). The common badness for languages is defined as the sum of badnesses that each puts on the quality of conversation for the language where this quality is maximum. The quality of conversation in a language is defined to be the minimum of the skills of both people in this language. - Are you ready to learn the other's language (check: 0 or 1 or 2) ? This would add this quantity to the quality of conversation in a language where the other's skill is better than yours, but not exceeding the other's skill. For each of the following, the user tells which is his situation, and how many penalties for every possible situation of the other: - (Nationality: not sure it is useful) - Smoker: s= 1) No 2) A little but I can stop 3) A little 4) Yes Requirement: how many points of penalties for possible values of the of the other's s'>s (while zero for the lower s') - Gender : M/F/other - drinking habits - Birth year - Marital status - Children already in charge (0,1,several) - Height - Weight - Eyes color (colors should be displayed) - Hair color (idem) - Hair style - Ethnicity - Religion or creed - Education - Income (range) - Handicap : no - a little - yes For each possible hobby or interest, same question: do you like (yes - a little - no) Badness if the other likes - if a little - if no Then, here are common badness criteria: - Geographical criteria: make a table with columns: Region | badness as a place for first meeting | would have an income there if a long-term living (yes/ a little or perhaps /no) | badness if other has | a little | won't have an income - Checkboxes (or active links) in front of divisible regions -> replaces in the table, the line of this region by as many lines as there are subsets of this region. When not divided, it means the same answer for all regions First are displayed the continents: North America - South america - Europa - other western-style regions or islands - Africa - Middle-East - East (ex- soviet union) - China - India Explanation: There are here two different criteria: First, the common badness for first place meeting is defined as the minimum over all geographical areas, of the sum for both people of the badnessed they put for this area. Second, the common badness for long-term living place is defined as the minimum over all geographical areas, of the sum of both badnesses for each other on this area, where the badness of a person A for the other B in an area is the one affected by B to the situation regarding income that A declared in this area. - Type of relationship: for each type of relationship, put the badness: - Holidays: - Correspondence: - Short relationship: - Long relationship : - Marriage: - Want children (zero for your choice, badness for the other) ? - Yes: - No: About changing parameters/criteria: The user is warned to be very careful while filling the fields as when he first sends his information, all the existing users of the system receive his file and won't re-receive it if he performs any changes. So changes will apply only to users who will register after him. (Is this right?) 3. The user enters any other text information describing him. Does he? 4. Upload a photo. There can be some constant limitations (file size, dimensions). The system should check them before accepting the picture. 5. When an account is created, a new forum "Photo & private info advices" is automatically created. Unlike usual ones, this forum shows photos of ppl who post messages. It can be accessed from the list of dating operations and from nowhere else. Others start to see the link "Give an advice" and click on them and leave messages explaining why, if they wish. The only admin of this forum will be The User. ============================================================================= ============================================================================= #000002: Creating a personal Web page. ================================ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Personal Web Pages can be public or private. The page is connected to one of user's pseudos. A pseudo can have any number of personal pages. Public can be viewed by everybody. Rights for private pages are editable. It is a part of the PWP's development. The user can pass the step of creating a page but in this case he won't be able to contact with his matches. ============================================================================= ============================================================================= #000003: Review and select new matches ("U" folder). ================================ 1. Choose parameters to display in the list of matches. 2. View the list of matches. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Here the user chooses the columns of the table of matches to be displayed. There must be some constant initial settings. 2. The list of matches the system found suitable for you. The user chooses (checks) the people who he thinks would maybe be interesting for him. Technically, in each pair of people {x,y} that the automatic selection had found as a possible match, there are two parameters: the status of x for y (that y chose to give to x), and the status of y for x. The following statuses exist: - unlisted (N) - unreviewed (U) - trashed (T) - delayed (D) - selected (S) - selected+ (S+) When one's account is created, his file is sent to other existing users matching one. So one becomes unreviewed ("U") for others. But one doesn't yet receive others' files (unless they select him). Thus, from the very beginning the user receives no files. But one's status for others (those who match him) is unlisted "N". When the user receives some new file, he checks matches he thinks he might be interested in page by page, so that the listed matches become trashed ("T"), selected ("S") or delayed ("D"). The user views the unreviewed list ("U" list) in the following way: two pop-ups are shown. One of them displays information about some number of the currently being viewed matches (the user views them and decides whether to select or not), the he finally clicks "next". Then another pop-up becomes active. The idea is to save time: the first pop-up is loaded while the second one is viewed and vise versa. When the user clicks next, another pop-up containing already loaded information about the next matches becomes active. The number of shown matches can be changed together with selecting the parameters to show. The default value is 10. The matches are displayed in the following order of priority: U/S+; U/S; U/N; U/U*. Matches with the same statuses are showed in the increasing order of the sum (B's penalties according to A's criteria + common penalties). U/S+ and U/S are matches which happen between the users and those who registered before the user, received user's file, reviewed, and selected the user causing their files to be sent to the user; U/N is when the user receives files of recently registered users. * We will implement the U/U status later. ============================================================================= ============================================================================= #000004: Select more closely. ================================ In this folder are listed the matches with statuses S/U and S+/U. (Notice: and D/anything and those blocked by absence of PWP.) It means that the user has already chosen these people with S or S+, but they haven't yet. Well, the user may either move someone to trash or update S status for S+ to possibly help starting contacting this match a bit earlier. This list can also display the matches which are blocked because of not having the personal web page. ============================================================================= ============================================================================= #000005: List of twofold selected matches. ================================ In this folder are listed the matches which have been chosen as S or S+ by the user and have also chose the user as S or S+. Every twofold selected match, when appears, causes a new private forum to be created and placed into "Dating forums" folder (child of "Private forums"). Near and in each forum is shown a photo of a user. In each forum are placed links to user's PWPs. ============================================================================= ============================================================================= #000006: Viewing the info pages of matches. ================================ The user must be able to do the following actions: 1. View the public web pages of twofold selected matches, 2. Invite the match to the own private web pages. >> You mean the second one ? This is no explicit operation. The only thing is to choose between S and S+. The status S+ means to give access to the second PWP if exists, else it just means "I love you". What if the user has several private web pages and wants some ppl to access not all of them but only some? Can the user invite somebody selected (but not selected+) to his private page? 3. View the user's second (private) page, if he is invited to. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ By the way, the user is to be able to change matches' statuses everywhere they appear between T, S, and S+. ============================================================================= |
|||
Lun 31
janvier 2005 |
Q: Please make more detailed
explanation: >> Others start to see the link "Give an advice" A> which is like two folders (one of men, one of women) Do you mean that two seperated forums are created and when smb clicks the link, he traps into either forum for men or forum for women so that men can't see women's advices and vice versa? A> containing all the A> photos with links to corresponing advice forum, containing all the photos of one person? A> only of people who asked A> for advice (until they deselect this request). So where does the link "Give an advice" lead? Q: During the registration, is the person asked whether he wants advices conserning his picture? Q: As I understand, the person can remove the forum of advices in future if he doesn't need them anymore (deselect this request), is that right? ----- > When sending profile it is tested with and received if > positive by all except those already received and found positive by > criteria (because they are already handled - those received and found > negative can be retested in case the parameters and criteria were > modified). Q: Will matches which were once found negative during the search be recalculated in future in the case of changing parameters or criteria? So when one changes his info/criteria, does this mean re-testing his profile with all already existing matches and sending it to those ones which became positive after (during) re-calculating? ----- |
|||
Lun 31 janvier 2005 |
- the dating system. =============================================================================>>>#000006: Viewing the info pages of matches. ================================ >>>The user must be able to do the following actions: >>>1. View the public web pages of twofold selected matches, >>>2. Invite the match to the own private web pages. >> You mean the second one ? This is no explicit operation. The only >> thing is to choose between S and S+. The status S+ means to give >> access to the second PWP if exists, else it just means "I love you". > Q: What if the user has several private web pages and wants some ppl to > access not all of them but only some? Then it should be possible but it is not specific to the dating system, but it is a general functionality to the PWP system, that remains to be done. > Q: Can the user invite somebody selected (but not selected+) to his > private page? Well, anyway, all people selected access the first page; and if there is a second one, the way to give access it is normally to make select+ : this status S+ has no other functionality than this possible access to the second page, and the fact of being displayed (once the other selected also), so why not use it ? |
|||
Lun 31 janvier 2005 |
> Hello, Sylvain. > > =============================================================================> #000001: Registration > ================================ > Actions: > > 1. Choose a pseudo. > 2. The user enters his parameters and search criteria (badnesses). > 3. The user enters any other information describing him. > 4. Upload a photo. > 5. Advices. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> > 1. The user chooses a pseudo under which to create a dating account. > The user can have an only dating account. In future he won't have > possibility to change this pseudo. Either, he won't have possibility to > remove this pseudo unless the dating account is removed. > > 2. The selection of possible partner will happen by a system of > negative points, called penalties. For each possible situation > concerning the parameters of the other person, the user will affect a > number of penalties from 0 to 40. The computer will consider a person > as a possible match so that each can review the other's profile, if the > following three conditions are satisfied: - His/her total number of > penalties in the user's criteria is lower than 40, - The user's total > number of penalties in his/her criteria is lower than 40, - The sum of > these two numbers and of the common badness penalties is lower than 70. > > Therefore, for each question, the user gives the number 0 to the best > possibility in his view, and 40 to what he wants to exclude. > > First, here are the criteria of selection of one by the other that > should not exceed 40. > > - Languages: for each possible language the user is asked to > enter the skill in the language: 0: not speaking > 1: something > 2: a little > 3: manage well > 4: good > 5: very good/native > > The user defines the badness to each possible quality of conversation > (gives a number of penalties for each of the six possible qualities of > conversation). This must be a decreasing series of numbers, as a poor > quality of conversation (0) has a bigger badness than a good one (5). > The common badness for languages is defined as the sum of badnesses > that each puts on the quality of conversation for the language where > this quality is maximum. Well, I'm seeing that I wrote this but in fact there is no need here to have the output to common badness, since the quality of conversation is uniquely defined, as the maximum of the quality of conversation over all languages, and each person attributes a given badness to this quality. Let's not do the smoking now, we'll add it later when we will decide how to do. I had the following idea: Smoking ? yes/no. If yes, what badness if the other dislikes smoke, for: - only smoking little inside - not smoking inside - only smoking little even outside - Stop smoking completely If no, what badness if the other smokes, for him/her: - smoking a little outside - smoking outside - smoking also a little inside - smoking inside The problem is that some people are "trying to quit", which complicates things ! Also, it is not obvious what output to make from computation: common badness or individual badness ? or a mix of both ? next questions later... |
|||
Lun 31 janvier 2005 |
> About changing parameters/criteria: > The user is warned to be very careful while filling the fields as when > he first sends his information, all the existing users of the system > receive his file and won't re-receive it if he performs any changes. So > changes will apply only to users who will register after him. (Is this > right?) Yes. > 3. The user enters any other text information describing him. Does he? No, that's the role of PWP. > 4. Upload a photo. > There can be some constant limitations (file size, dimensions). The > system should check them before accepting the picture. Yes. > 5. When an account is created, a new forum "Photo & private info > advices" is automatically created. Unlike usual ones, this forum shows > photos of ppl who post messages. ??? No. This shows only the photo of the involved dating account. And it is only to discuss photo. > It can be accessed from the list of > dating operations and from nowhere else. Others start to see the link > "Give an advice" which is like two folders (one of men, one of women) containing all the photos with links to corresponing advice forum, only of people who asked for advice (until they deselect this request). > and click on them and leave messages explaining why, > if they wish. The only admin of this forum will be The User. > > =============================================================================> > =============================================================================> #000002: Creating a personal Web page. > ================================ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> Personal Web Pages can be public or private. The page is connected to > one of user's pseudos. A pseudo can have any number of personal pages. > Public can be viewed by everybody. Rights for private pages are > editable. It is a part of the PWP's development. The user can pass the > step of creating a page but in this case he won't be able to contact > with his matches. > ============================================================================= I mean, something where pages only have the functions of: - Module for uploading photos, which gives their URL For edition of the web page: like in a wiki, only the "content" is editable whereas the header remains fixed, which contains the author's pseudo linked to his info page... and other things we will discuss later, and which will be related to GLS. So, the editing of content gives the possibilities of: - having titles (one style is enough) and paragraphs - putting links - including photos (where one types the URL of photo) |
|||
Lun 31 janvier 2005 |
> When one's account is created, his file is sent to other existing users > matching one. Not immediately. First the dating account is created to start filling and editing parameters... Then when it is ready, one can activate the account (to receive profiles), then send profile. When sending profile it is tested with and received if positive by all except those already received and found positive by criteria (because they are already handled - those received and found negative can be retested in case the parameters and criteria were modified). > So one becomes unreviewed ("U") for others. But one > doesn't yet receive others' files (unless they select him). Thus, from > the very beginning the user receives no files. more precisely, he starts receiving the files that will be sent, when they will, not those which were sent before activation. > But one's status for > others (those who match him) is unlisted "N". ? Unlisted is what the others'servers "think" that their status is for him. |
|||
Mar 1 février 2005 | Check the attached .doc-file. |
|||
Mar 1 février 2005 |
The last idea of making global public forums including particular photos asking for advice as threads makes "The only admin of this forum will be The User." obsolete. Don't care about admin right, let it be the superuser of the system for example but it is not a significant question in the project. "By the way, what if we’ll separate it into two or three sub-lists: a) S/U, S+/U; b) D/*; c) temporary blocked?" Yes. "The only difference of S+/U status comparing to S/U is in allowing selected+ matches to view private web pages by default." No: it is the difference between (S+/S or S+/S+) and (S/S or S/S+) to view the second web page by default if it exists (while the first is always visible), whereas the difference between and S+/U and S/U is in the priority of display for review (while the web page is not visible). |
|||
Mar 1 février 2005 |
> Q: Please make more detailed explanation: >>> Others start to see the link "Give an advice" > A> which is like two folders (one of men, one of women) > Do you mean that two seperated forums are created and when smb clicks > the link, he traps into either forum for men or forum for women so that > men can't see women's advices and vice versa? ok so to make a more specific description: Let there be only two such public forums, once and for all (as long as the dating system only works inside one site without GLS).One for photos of men where women post advices, and one conversely. In this forum, there is one thread per profile who asked for advice, and with it only one photo, the main photo of the profile (i.e. not the PWP). In the forum of men's photos, women access by their link "Give an advice", men access by a link aside their option "Ask for advice" which leads them directly to their personal thread.And vice versa. > A> containing all the > A> photos with links to corresponing advice forum, > containing all the photos of one person? I meant the photos of all the people, one per person - now I say: link to the corresponding thread. > Q: During the registration, is the person asked whether he wants > advices conserning his picture? Yes. > Q: As I understand, the person can remove the forum of advices in > future if he doesn't need them anymore (deselect this request), is that > right? Yes. >> When sending profile it is tested with and received if >> positive by all except those already received and found positive by >> criteria (because they are already handled - those received and found >> negative can be retested in case the parameters and criteria were >> modified). > Q: Will matches which were once found negative during the search be > recalculated in future in the case of changing parameters or criteria? Well ok we can consider this, but with a limit in frequency: no more than twice in 4 months for example. I considered doing this exception above because it happens that one may not have put the perfect data at the first try, and the fact of activating profile before sending it is just here to give one a chance to make a last correction before the important action of sending profile. > So when one changes his info/criteria, does this mean re-testing his > profile with all already existing matches and sending it to those ones > which became positive after (during) re-calculating? Yes, one can give the option after modifications (which can be done at any time) to re-send modified profile, but, as I said, with a limited frequency.You need not implement this at first. |
|||
Mer 2 février 2005 |
- There is work to do for GLS (you know well you need what to send requests between hosts) and bookmarks (to link not only to the root of sites but also to PWP, and relate closely bookmarks with links in PWP) - I also asked about how is the database and way of working of GLS and got no answer. - The webmail should be integrated to the forum and be a webmail and invitations system (to send by email invitation to join the system) - Have groups of PWP with for each group some handling of rights to read and write Moreover I even don't have the code for their PWP editor, |
|||
Jeu 3
février 2005 |
Q: Will matches which were once
found negative during the search be recalculated in future in the case of changing parameters or criteria? So when one changes his info/criteria, does this mean re-testing his profile with all already existing matches and sending it to those ones which became positive after (during) re-calculating? Q: So, we decided to make a global public forum containing photos of asking for advice people as threads, didn't we? And to put a link to an apprpriate thread near each one's photo on an info page, right? Q: Is there an option "ask for advices" while registration? I mean, has the user a possibility to reject asking for advices frmo the very beginning? The user can uncheck this option in future, can't he? |
|||
Jeu 3 février 2005 |
Q: Will matches which were once found negative during the search be recalculated in future in the case of changing parameters or criteria? So when one changes his info/criteria, does this mean re-testing his profile with all already existing matches and sending it to those ones which became positive after (during) re-calculating? It should not be automatic, so re-testing can be an available function after modification, but limited in frequency. Q: So, we decided to make a global public forum containing photos of asking for advice people as threads, didn't we? Yes, two forums, one for men's photos, one for women's photos. > And to put a link to an > apprpriate thread near each one's photo on an info page, right? Yes... what info page are you speaking about ? Well, reading again your document I see you make a difference between #000005: List of twofold selected matches. and #000006: Viewing the info pages of matches. I did not pay attention to that. I meant that the links to PWP of each match were present inside the list of twofold selected matches itself. Ok, let there be also all links in the info page of match which is the page displaying all parameters of that profile (whereas the search criteria remain invisible). The link to thread of photo can be on one's own dating account, and in each matches list for each match. But in fact, the only matches list where it is necessary to have this link is the list of delayed matches. > Q: Is there an option "ask for advices" while registration? I mean, has > the user a possibility to reject asking for advices frmo the very > beginning? > The user can uncheck this option in future, can't he? Yes. I'm thinking of one detail: in the decision to ask for advice or not, in fact it is in the absolute not one possibility among 2 but among 3:The thread may exist but not appearing when one looks a the forum (the list threads). So I wonder if we should keep all three possibilities or only 2 and which ones: should the threads of those who don't ask for advice exist while being invisible in the forum, but be only accessible from the delayed matches list ? ---------------------------------------------------------------------------------------------- |
|||
7 feb 2005 |
techdesc2.doc | |||
7 feb 2005 |
- PWP, GLS and webmail. -Dating System Some notes from programmers: ========================================================================== -I pressed "submit" at login.php, I got a lot of notices (see webmail.txt attached) and nothing more. Then I started to receive "No input file specified." message in my browser window (as I remember, it's a message of GLS). Sometimes I just get HTTP 404 error. Possibly, I was mistaken somewhere while importing and setting the DB. - tables (gls_users,users,gls_bookmarks,gls_code_keys,wm_users) which have duplicate fields (with equal names) I can't understand the exact difference between. ==> describe these tables and their fields to help me install the system correctly? - What concerns GLS: in 'gls/libs' folder I see classes which implement (I suppose) the functionality of GLS, but I see only ones which perform logging in, some crypting ones and nothing more. - dating system and finish forums, I need libraries which would implement queries between registered servers and as - Bookmarks didn't work. ========================================================================== -for every set of pages there must be a different set of permissions (a different list of users that can see it, or see and edit it).Also, set allow for invitations or not (one that can see can give right tosee to someone else). - dating system to work, the following features of PWP will be necessary: ---> groups of personal web pages (for example, a group of pages is identifies by the fact it is the pages inside a given folder). ---> For each group, a different set of rights (viewing public / private for a given list of people attached to this group) (writing personal/public/reserved for a set of people). ---> The dating program will handle the list of people that may view the page. --> create editing functions that can be called by other programs. --> The home site will produce (in dating matches lists) direct links to PWP of other sites that make the GLS authentication.So, this is more general than bookmarks to the root of another site: it is bookmark to a PWP; and those bookmarks will be integrated as links in pages from home site that run in their own ways. - Integrate the webmail, making it a "webmail and invitations" system by which email correspondents can register and: * be added to the contacts of the inviter * be recorded as having been invited by that person, so that the site's admin can see it, and see the chain of invitations that leads to anyone - Integrate the PWP with a system of groups of web pages with their rights, and ways to directly link to a page by GLS as I said. - GLS 1) In each server, a list of peer servers with their respective domain names (or URL) and public keys, and as I recently suggested, the nickname of each server, in order to not be slaves of the long domain names that could be found for their DNS. - any user to invite a new server to be a peer server of the network. Until then, to be simple we can just let the admin of each server enter by hand this list of servers with their public keys 2) From this, automatically generate a symmetric key with each peer server to add to the above table 3) Let each user of the server have his own bookmarks list. A first kind of bookmark will be simply to the root of another server of the network. Therefore it makes no sense for the user to enter the URL by hand. He need just select it inside the list of known peer servers, the 1) above.( the pseudo should be selected from the list of existing user's pseudos, and not mascarade as someone else).A second kind of bookmark will be to particularthings in other servers; so there should be a way to identify web pages, forums and threads, where:- Anywhereyou are, you can "copy the address of this page to clipboard", "add this page to bookmarks list" or simply view its address/identity on the top of the window- You can paste the link into a web page, a message of forum, yourbookmarks list. I know forums is not your work but this problem must find a solution one day anyway. - every link from a PWP to a PWP be a link to go anonymously;but on the right of the link, have an icon like a little book to bookmark the link (add to the user's home site bookmarks).When editing a PWP, give the possibility to paste a link from bookmarks, or more precisely (preselecting among bookmarks) the last bookmarked page. - more about GLS In the bookmark list there should be the possibility to modify the pseudo used for every bookmark, inside the list of one's pseudos plus "Anonymous" (to visit publically visible pages).I also think one should include in the transfered info, together with the pseudo, the choice of prefered language for the interface: on top of the PWP one visits there are links to Author - bookmark/unbookmark this page - see my bookmarks - logout and so on as I said (do you remember when I described what I wanted long ago): unless you replace them all by pictures you need to choose the language - anyway it will have other uses, in particular in the future when one makes versions of one's page in different languages. |
|||
Lun 7 février 2005 |
(system of rigths of PWP): - for every set of pages : different set of permissions - different list of users that can see it, or see and edit it - set allow for invitations or not (one that can see can give right tosee to someone else). - dating system to work, the following features of PWP will be necessary: Make groups of personal web pages (for example, a group of pages is identifies by the fact it is the pages inside a given folder).For each group, adifferent set of rights (viewing public / private for a given list of people attached to this group) (writing personal/public/reserved for a set of people). Having only the personal writing is OK for now. The dating program will handle the list of people that may view the page. So, create editing functions that can be called by other programs. The home site will produce (in dating matches lists) direct links to PWP of other sites that make the GLS authentication.So, this is more general than bookmarks to the root of another site: it is bookmark to a PWP; and those bookmarks will be integrated as links in pages from home site that run in their own ways. - new version of the forum. - Integrate the webmail, making it a "webmail and invitations" system by which email correspondents can register and: * be added to the contacts of the inviter * be recorded as having been invited by that person, so that the site's admin can see it, and see the chain of invitations that leads to anyone - Integrate the PWP with a system of groups of web pages with their rights, and ways to directly link to a page by GLS as I said. Thank you very much. I will probably come in February (I can't be sure of the exact time now). Subject: What I want with GLS 1) In each server, a list of peer servers with their respective domain names (or URL) and public keys, and as I recently suggested, the nickname of each server, in order to not be slaves of the long domain names that could be found for their DNS. Another time we can develop a way for any user to invite a new server to be a peer server of the network. Until then, to be simple we can just let the admin of each server enter by hand this list of servers with their public keys 2) From this, automatically generate a symmetric key with each peer server to add to the above table 3) Let each user of the server have his own bookmarks list. A first kind of bookmark will be simply to the root of another server of the network. Therefore it makes no sense for the user to enter the URL by hand. He need just select it inside the list of known peer servers, the 1) above.(I also noticedsomething wrong with the user's pseudo used in bookmark: the pseudo should be selected from the list of existing user's pseudos, and not mascarade as someone else).A second kind of bookmark will be to particularthings in other servers; so there should be a way to identify web pages, forums and threads, where:- Anywhereyou are, you can "copy the address of this page to clipboard", "add this page to bookmarks list" or simply view its address/identity on the top of the window- You can paste the link into a web page, a message of forum, yourbookmarks list. I know forums is not your work but this problem must find a solution one day anyway. Hi. To be more specific, I just thought about how for example to do with links in your PWP:Have every link from a PWP to a PWP be a link to go anonymously;but on the right of the link, have an icon like a little book to bookmark the link (add to the user's home site bookmarks).When editing a PWP, give the possibility to paste a link from bookmarks, or more precisely (preselecting among bookmarks) the last bookmarked page. more about GLS In the bookmark list there should be the possibility to modify the pseudo used for every bookmark, inside the list of one's pseudos plus "Anonymous" (to visit publically visible pages).I also think one should include in the transfered info, together with the pseudo, the choice of prefered language for the interface: on top of the PWP one visits there are links to Author - bookmark/unbookmark this page - see my bookmarks - logout and so on as I said (do you remember when I described what I wanted long ago): unless you replace them all by pictures you need to choose the language - anyway it will have other uses, in particular in the future when one makes versions of one's page in different languages. |
|||
Mar 8 février 2005 |
For each parameter, will be a number of penalties, or of common penalties. Then will be computed the sums of the numbers of penalties over all parameters/criteria, giving 3 total numbers: the total number of A's penalties for B, of B's penalties for A, and of other common penalties. The "ask for advice" is only for photo, so the thread is created when "ask for advice" is chosen, and this question can be set only after photo has been uploaded (or photo URL has been given). The computation of badness of type of relationship and want children is similar as geographical criteria (minimum over all possibilities of the sum of badnesses). "** - I think it would be right because maybe somebody would like to leave a message (advice) having decided to trash the match anyway." Good remark. I read down to #2 included. Please tell me if you made any further correction after those ones, that I should read again. |
|||
Jeu 10 février 2005 | > #000001. I updated this part according to what you said about > badnesses of relaitionships, about threads of asking for advice forum, > and about penalties and common penalties. > > A> I read down to #2 included. Please tell me if you made any further > A> correction after those ones, that I should read again. > > #000003. > One can change his parameters or search criteria. It doesn’t > automatically cause re-searching new matches among all the existing > users of the system; it only touches detecting whether one matches > users who register after. But one has an option “re-send my profile” to > launch the re-testing his profile and sending it to suitable > matches. This function must be limited in frequency. > > Q: Ask for advice: So, we decided to let three choices exist: > - Ask for advices about his photo, > - Don’t ask for advices but let the users leave corresponding messages > if they wish, - Decline to receive such messages, > Didn't we? OK > Q: In the third case, can such user be set a "D" status? Yes. So, that's OK and you can start implementation. Thank you. Now the next things to discuss will be GLS, (webmail and invitations) and PWP. ---------------------------------------------------------------------------------------------- |
|||
Jeu 10 février 2005 |
I think we can start with GLS for the first time. Step-by-step Preposition from our side: 1) Discussing every module (ex. GLS, WebMail, Invitaion, PWP etc). 2) Description preparation (like Dating-system spec at this time). 3) Project specification approvement. 4) Object description preparation (for programming). 5) Database planning and normalization. 6) Coding. 7) Testing stage. 8) MileStone. |
|||
Jeu 10 février 2005 |
http://freelancewebprogramming.com/projectdetails.php?id=13528 [voir copie de cette page tout en bas] (...) Do you mean to let the user browse the page anonymously ? Well, it may depend on the cases: some pages can be public thus browsed anonymously, some other may require authentication. I wonder if it's possible to automatically redirect to the home server to make the authentication but maybe not. Anyway we can do without. For private pages the answer will just be "Error: you are not authentified", and eventually display again what request to type inside the home account to come back to this page. > And this list will be different depending on what site user visits Not sure what you mean. Each user has his own list of bookmarks. Eventually they may be organised in folders (for example displayed like in bookmarks.html) according to the host or not. Propose an example of solution, even if not sophisticated. Let's not too much focus on this question now. > What is the main language for your whole project in global? Is it php or > Java? For now it's php. I heard that in general, different langages can interface well with each other. So it is better to make things so that it can be easily called from other languages. Is it a problem ? Sorry I don't know enough about languages to figure out the problem. I think you understood. > Using this key we can gather information about login, > password, host from which user came, etc In the version to do now, these information will be just those sent by the home site.So your task is to make a program accessible as a kind of function at thehome server that can receive any number of parameters that are all info it wants to send, without any request initiative from the visited site.Later new features could be developed for requests of info but not for the present work. More precisely I spoke about having a list of bookmarks with the said functionalities. In fact, what I expect from you more precisely is not to make the display of that bookmark page but to make a set of elementary functions of authentication and info exchange between sites, not including any particular display, letting open the list of parameters to be transmitted, such that it would be easy to make the said bookmarks pages in php or any language using a call to these functions. You see that in my project there will be a use of these functions in a context of other kinds of displays than the simple list of bookmarks. That is, the display of all forums contained in a "box". For this and for other future contexts of uses, I need to have available the function "Make a link on this piece of text to that page of that site in an authentified way, and transmitting those values for those variables" (although the info of "that page" to go to may be as well included in the parameters transmited to that site). Effectively programming a bookmarks page can be interesting, maybe for being used as such, but also more interestingly as a simple example of a demo of how these functions can be called.So, don't bother to organize the bookmarksinto folders. Just make a very simple program (for example in php) that takes the list of links from a table and displays it simply one above the other using your functions in java or not, but links to request your java program that will do the work. But I wonder how future uses can stay free to program the decision of what info to send, without passing this info in clear in the request from the bookmarks page to the call to one's home page for authentfiied redirection: even if it goes through SSL it is insecure in the sense that the user himself if he is malicious, might trick the data. The data to transmit should never be modifiable directly by the user.Do you have a solution forthis ? An idea would be to have (for each user ??) a mysql table of all links and of the parameters to include, so that a link on the bookmarks page can just keep the incremental number refering the link so the redirection program will just take the data from the database, crypt it if not already done and send it.The two advantages compared to the idea of having crypted requestto other server already included in the bookmarks page are that it makes a less heavy html page and that it keeps track of sessions to make possible the general logout. -- |
|||
Ven 11 février 2005 |
- display of new matches in the new matches folder, how to either select, trash or delay. Trash will be by not doing anything. I think that Select will be by cheching box while Delay will be by clicking on a "?". I'm only wondering what should happen on the display once the "?" has been clicked, and whether it sends a request to the site immediately or only as an info among others in the form. I'm also wondering whether profiles should appear as lines or columns. Appearing by columns would allow for more information to be displayed in the same screen without using the lift. Unless, of course, we have a presentation with 2 columns (2 columns * 5 lines = 10 matches) as ______ | |info1 o |photo|info2 (other photo, other info) ? |_____|info3 (other photos, other info) (other photos, other info) .... (where "o" is the checkbox) |
|||
Sam 12 février 2005 | [what I suggested before he insisted to make "checklogin" function instead:] > e. find out, is such user logged in or not? we can do this by accessing > to a> database of the reffering host and seing the list of active users. In my idea, this info comes from the fact that the request being first processed by the home server of the user where he is logged in, it checks the loginis still on and includes the date and time of request in the coded info, and theother host decrypting the info checks that the date and time are the present ones. (...) > user login, user password No. The user password must not be known by any other host than the home site of the user, for obvious security reasons: I want a general internet, not the service of a central organisation.There should not be any possibility formalicious sites receiving the visit of a user, to take the control of the account of this user.Moreover, in myproject the chosen pseudo of user is transmitted, not the login. Anyway this can just be part of general parameters. [the symmetric keys] > Soone or later > (better later) they WILL get in ot wrong hands How (sorry I'm not expert in cryptography) ? I would think that each key being between two sites only, they should not be known by other machine.Do you meanthere is a way to analyse the crypted info exchanged to deduce which key is used ?I suppose the answer is no, else, if it is just a matter of timeto find the key, no crypting can resist long enough attacks for decryption (as I heard that pgp encryption is the encryption of a symmetric key plus message crypted using this symmetric key. Do you mean using the same key 1000 times gives the possibility to find the key easier by analysing those crypted data than if is is used only once ? Do you mean decrypting one key is possible but decrypting all 365 keys generated every day of a given year multiplies the calculation time by 365 and thus makes it unreasonable while only decrypting the one day requests is not interesting enough (or cannot be done inside the day so that key broken cannot be used to create fake info ? but if hackers parallelise the work enough I'm afraid this makes not much difference) ?In my idea there is a network of 10,000 independent sites where each user of each site visits different other sites, so every key for a pair of hosts is not so much used and there are many enough such key (about 50,000,000) to make it too difficult for hackers to have a significant impact if they break only a few of those keys. So maybe regularly changing the keys is good but probably not as often as once a day (only before or after use for example). From any centralised idea to its decentralised version there is a simple way : let the home site of each given user serve as his own data center for all his requests. Hello. I think that among the next tasks I have proposed you to do (in parallel or after the present one), the one that would be more logicalfor you to doas it has more connection with the problem you are working on will be the personal web pages. For now, I expect you to undertake the task I gave you, for example in the way I proposed last time,unless you find a better idea but at least you shouldconsider this as a good example ofa flexible solution expressing the way I need things to work from theoutside:Having the list of links (with corresponding info to be sent) in a database table so that any furtherdevelopment of the project can be made by storingin this table for every link the desired parameterstogether with the link, then when the link is clicked,the java program, after checking the session fromcookie, takes the parameter from the database, includes the date and time of request,crypts this and sends the crypted version with the redirection. The other site target of the redirection can be also a java program that takes noticeof which host this redirection comes from, decrypts the request, checksthe date (and maybe user IP ? is it useful ?)and opens a session giving obtainedparameters (including host name) for other programs to process (for example in session variables). Though as I said I don't know much of programming, I suppose this explanation does not leave atoo big mystery of how all the thing can ever be done. Thank you. Hello. Finally I think I would be also interested to find someone more to do the webmail and invitations part in parallel, in order to ensure a quicker release of my project. Would you be interested to do it soon or would you know any other team that may be interested (you can forward to them this description - propose a price and I will see) ? Precisely (the description is on my project page, here is maybe a few more details): - Concerning the webmail fonctionalities itself I'm not looking for anything sophisticated. Just a simple way of working, in a multi-language environment, with sent mails stored. Since my project is under GPL, if I understand well the GPL license, it is acceptable to use for start, a copy of any existing GPL webmail or component of webmail provided that you mention the source. - What is important is to share the login system with the one of my project, and that the webmail function appears as one of the things to access from the menu. - Possibility of several email addresses per user, more precisely addresses given by some of their pseudos - Possibility to send invitation to the system, that is, an URL with randomly generated identifyer where the receiver of the message can register (the registration form already exists). In the description on my site I told about adding a standard invitation message in a desired language. If this trick is not quick to implement, it need not be made in a first version, but just add a bare URL with parameter at the bottom, and rely on the sender to add the useful explanations. - Adding automatically the pseudo of the new user in the list of contacts of the user that invited him (in my project there already is a list of contacts; the problem is to make things work together, mixing emails for the outside and contacts internal to the system). Let the invitations tree between users be recorded in a database. Thank you. From Frozen Team: Hello, Here is what we have discussed about our Global Login System. First I will give you common functions, then - execution logic, then some questions. 1. COMMON PROTOCOL FOR ELEMENTARY FUNCTIONS: 1.1.Function name: authotentificate (not sure if my spelling is right :\) Description: authotentificates user on remote host which is specified in bookmark link. Function is sent to remote host when user clicks bookmark. Params: HomeUserID - identification parameter on home site (can be login or ID in database) TargetLogin - login on remote system where we try to authotentificate (optional) HomeLoginSystemURL - parameter needed for function checkLogin (see checkLogin). 1.2.Function name: logout Description: performs logout on home site. Function is sent to home site. Params: HomeUserID - identification parameter on home site (can be login or ID in database) 1.3.Function name: checkLogin Description: checks if user is logged in at the home site. Function is sent to home site using HomeLoginSystemURL passed with "authotentificate" function. This function refreshes time of user's last activity if this time is less than session's expiration time otherwise it will redirect user to home site login page. Function is sent to home site. Params: HomeUserID - identification parameter on home site (can be login or ID in database) 1.4.Function name: getBookmarkList Description: gets bookmark list from home site in plain html format. Function is sent to home site. Params: HomeUserID - identification parameter on home site (can be login or ID in database) 1.5.Function name: addBookmark Description: Adds bookmark to home site bookmark list. Function is sent to home site. Params: HomeUserID - identification parameter on home site (can be login or ID in database) BookmarkLink - link to the page to bookmark TargetLogin - login to use at site specified in the link of the bookmark(optional) 1.6.Function name: removeBookmark Description: Removes bookmark to home site bookmark list. Function is sent to home site. Params: HomeUserID - identification parameter on home site (can be login or ID in database) BookmarkID - identificator of bookmark (i.e. in database) 1.7.Function name: editBookmark Description: Edits bookmark in home site bookmark list. Function is sent to home site. Params: HomeUserID - identification parameter on home site (can be login or ID in database) BookmarkID - identificator of bookmark (i.e. in database) TargetLogin - login to use at site specified in the link of the bookmark(optional) 2. ACTIVITY LOGICS: Here we will track user from the beginning. Step by step. 2.1.User first came to the network. This is the first time users is in our network. He registers at one of the sites ofour system. He gets access to: first of all - bookmark page, later - webmail, invitation systems, etc. We think that we should have access basic bookmarks list (list of sites of oursystem) that will be accessible for every new user. 2.2.Sooner or later user clicks bookmark. User is redirected to the site bookmark of which he just clicked. Additional information of bookmark link contains only the information of user's home site. Atfirst user is not registered (user has not login) at the site he/she has entered. 2.3.user enters bookmarked site. Our global login system processes this user. It checks the following: IF there is a key specified. If yes than system tries to decode coded informationand sets user's login flags (i.e. flag LOGGED_IN=true in session). If No key isspecified user is passed to local login system which desides what pages to show tounauthorized user. 2.4.User registers at new site. User clicks "Register" links ont this site, local login system registers him/her.That it checks the following: if there exists information sbout user and his/herhome site in, for example, session, than local login system sends EditBookmartcommand to home site with the foolowing params: HomeUserID, BookmarkID, TargetLogin(this is the logn we have entered during registration at the bookmarked host. If wemodify bookmark with this login (as you call it - pseudo) to automatically login wheyou click this bookmark next time). 2.5.Users is browsing through sites using bookmarks. see p. 2.3. 3. QUESTIONS: 3.1. What should we do with not valid request (i.e. if invalid key is specified, ifno key is specified)? 3.2. Is there is a bookmark list associated with some host? Some host we think canhave a little different bookmarks than other. (For example site dedicated to WWIIshould have bookmarks to other sites concerning this thematics, but not gardenerssite). Thank you for specifications. Here are my comments: For each function, you should tell not only "sent to" (i.e. where it is executed) but also "sent by", that is, where does the request come from: is it another program on the same server, or is it a function directly requestedby the user or by another server. 1.1.Function name: authenticate (if I don't mistake) Maybe I should have more insisted: my login system is already a bit more complex thanthe usual ones, in that every user can have several pseudos, and only thehome site of the user should know what pseudos belong to the same login. So, insteadof HomeUserID or TargetLogin it will be pseudo or maybe pseudoID (do you think it is usefulfor the servers to associate to every pseudo a pseudoID that is anumber, to make things run faster ?). In a sense we could say that the home server manages TargetLogins itself, except that it is pseudos that are of universal possible use and recognised by the home server, not only at a fixed remote server. In the user's table of links, the user can configure the data: for each link, under whichof his pseudos he will be authenticated. Something more: in fact I will need not only one list of bookmarks per user but several kinds of links. Well, all could be kept in the same mysql table for each userwith a parameter "type of link" so that each development of the bigproject can choose to handleonly the type of links it is concerned with, while itcould remain possible to display the whole list. (I hesitate between this and having a separate table for each type of link)So, for each user there would be a mysql table of linkswith parameters including"chosen pseudo", "type of link", and for sometimes possibly "title oflink" (text to display under the link)- possibly also one more field to identifythis link in the context of applicationExample: some links would be of type "link to a private forum" (this willbe my firstmain application of this system). See list of table fields for the user'stable offorums in my todo file. Entries (lines) in this table would correspond tobookmarks in the bookmarks list.Or could these two tables be made into one (andseparate from tables of other types of bookmarks) ? HomeLoginSystemURL: maybe you are right, I don't know. My first idea was to suppose that this thing was fixed and stored in the table of other hosts in the database of each host, as a contact address to send any requests to other hosts. Logout: well I don't see well the point: where is this function requested from ?Do you consider that remote servers can request it as asked by users visiting them ?Does it send logout requests to all other host that user connected to ? All of this maybe ? If requested through remote hosts, then the home host must find the user from the pseudo.Or there can be partial logout, where the userlogs out from a remote host that notices the home host about it, CheckLogin: seems not all right, as the last activity of the user can have happened at a remote host. So if you want to makea timeout and let this timeout becounted from last activity of the user on any of the hosts,it maybe a bit complicated to update the last activity time fromeverywhere. An idea would be: let T be the half timeout duration, the same for all sites for a given user.Each host would have recorded its own LATU ("last activitytime update") recorded for each user, and have the following rule: For each activity request at a time t: - If t < LATU+T then the activity passes through without bothering - If LATU+T < t < LATU+2T then new LATU := t and this is new LATU is sent to home server, to let also HSLATU := t (home server LATU)- If t > LATU+2T then acheck login is requested from the home server, and - If t < HSLATU + 2T then do like the second case - If t > HSLATU + 2T then the login is no more valid and a login prompt at home server appears Unless the home server sends itself logout requests to remote hosts as time t= HSLATU+2T ? 1.4. GetBookmarkList: what is this function requested by ? Just to help us debugging the system ? There could be: DisplayBookmarks (in an active way in an html page), or: display bookmarks of a given type. 2.1. Well I would like your work to be integrated into the rest of my project, where new users could freely register(until invitation system restrictsregistration) and user already access some functions (viewing public or private forum, see contacts). Okay for basic bookmarks list, at least to test the system. In fact, public forums hosted elsewhere will be as such. 2.2. "additional information" you mean received by target site ? I said the home site can include info to send to the target site.This list of info is openbut contains at least one pseudo of his the user choosed.In the case of forum it contains also the id of the forum and the invitation id of the user in the forum.(in my todo list I did not include the pseudoin the user's table of forums but I should add this, though it is redundant). 2.3. Remote hosts takes notice what is the home host that the user is coming from (from previous URL or from host ID included in the request), then takes from the database the key associated to this hostand decrypts the information by this key. There is not such a thing as registration in the remote server. You know there exists LINUX distributions to be run based on CD that never accesses thehard drive. In a similar way, you should not be surprised by the idea thatthe remote hosts receives authentified users from elsewhere while never registeringany account for them. (Only in forums tables of users there is mentionthat so-and-sopseudo from that host is allowed to access this forum). So there will be no 2.4 step, at least for now. Later, in a future task, we can consider tolet users register a "real account" in a remote host. If ever we consider the possibility that the user chooses a new pseudo when he is in theremote server, then a request should be sent to the home server toverify that this pseudois not taken by someone else, or else this pseudo is either an existingpseudo of thatuser or it becomes so, namely, pseudo@homeserver becomes a new universalidentificationfor the user if it was not yet so. Let's not bother about it for now. In future developments we can consider the possibility for the user to register another home accountat another host, by which he can create more pseudosthere (thanks to which he isnot anymore publicly known as being from his main home server). This is not for the present work. 2.5. what do you mean ? The normal way of working will be that bookmarks for a userare centralised by the home server. If a user wants to follow a link froma remote server Ato another remote server B in an authentified way, the link on thepage of A is technicallya link to a jsp program on the user's home server (together withinformation) that will addthe bookmark in the bookmarks list of the user and redirect to the next server. So, this link is dynamically generateddepending on where the user visitingthe page is from. 3.1. Don't bother. Maybe just display "Error: user not authentified". 3.2. Not your task for the present work. From Frozen team: Hello! Soory, my fault, I wrote not all things which are needed to fully understand what weare proposing. So. >For each function, you should tell not only "sent to" >(i.e. where it is executed) but also "sent by", that >is, where does the request come from I dont think this is necessary, we can get information from where user came fromrequest itself (it contains reffering URL inside) How our system will work. It MUST be called on every page where authentication of user is needed (or even onall pages, I will explain later why). This could be just an include statement in PHPor Java, but let's leave this question for later. After it is called we check whatcommand came and process it. checkLogin function. this function will be sent to home site from every page user is visiting. We don'tcare what page is user visiting, is it page of the home site or is it page on someremote host. The point is that every time checkLogin if received by home site - lastactivity time of user is updated, so, we can track user activity from every page. logout function. It can also be sent from any page to home site to log user of _on home site_. Imagine the follwing, user clicks LogOut, logout function is sent to home site anduser is deleted from active logged in users list. Next Users tries to navigate tothe page which requires authorization. checkLogin function is sent to home site butit will fail cause user is logged off from home site, and so he appears to be loggedoff from all other sites. GetBookmarkList: It will work as your DisplayBookmarks -) Still some questions: 1. Could you please give us more details of how registration will be comleted ondifferent sites, why some sites do not have registration (if there is no registration how user will get a pseudo on this site?). 2. As I understood there will a great number of so called home servers (where userscan register and this server will become his home site). The question is: what iftoday user comes to site www.site1.com and registers there. Tomorrow he comes towww.site2.com and registers there. So he will have 2 different home sites with 2logins. Maybe it is necessary to merge this logins some how? Or we shouldn't botherabout this? Please give us as detailed info as possible, so we could continue implememtation tohave a demo application ready as soon as possible. Thank you. Best regards, Vadim " >For each function, you should tell not only "sent to" >(i.e. where it is executed) but also "sent by", that >is, where does the request come from I dont think this is necessary, we can get information from where user came fromrequest itself (it contains reffering URL inside) " Maybe I did not explain well what question I was asking :-/ I was asking a technical question, that is, is the function requested by the userdirectly accessing this server that makes the operation, or by another server and in what circumstance. "It MUST be called on every page where authentication of user is needed (or even onall pages, I will explain later why). " Very strange statement, I did not think that way. I considered that for every session in the home server, the user can use his bookmarks butfor every remote host he need to create a session there only once,then the session existsand he can use it for as many pages as he wants. I suppose that making this authentication procedure again is heavier than just using an existing session. This is why I would favor using a session. checkLogin function. "this function will be sent to home site from every page user is visiting" (So, this is a direct request from remote server I suppose ?) Interesting idea but I'm afraid it increases traffic in an unnecessary way. Anyway, for every page it is necessary to check the cookie to verify the session. My idea reduces traffic at the only cost of having a margin of indetermination from 1 to 2 in the timeout.All right, in exchange you save trafficduring the logout operation. Still globally you involve more traffic than me. And the traffic you involve is when user is waiting for access to his pagewhile during logout, homeserver could send all logout request at the same time in background even after displaying "Logout request is noted and processing". "1. Could you please give us more details of how registration will be comleted ondifferent sites, why some sites do not have registration (if there is noregistration how user will get a pseudo on this site?)." Home server of a user = server where user is registered. Remote server of a user = where user can have a session but is not registered.His pseudo there, was first communicated inside the crypted info, then iskept among session variables together with id of home server and other parameters (I know about session variables in PHP). You do not deal with registration in this task (only the webmail and invitation part deals with registration). "2. As I understood there will a great number of so called home servers " Yes, any server can be the home server of some users (for example, about thousands of users each), and there can be thousands of servers, so that there can be many millions of users in the network. No you should not bother now about the case when user is registered at several places.More work on possible further registration may come later, with furtherdevelopments of the project.Now for the present task, the user is supposed to register at only one place, as the systemwe're making is designed to try to make generally useless anyfurther registration.Being registered at one place should be sufficient for all. The rest issessions. "Please give us as detailed info as possible, so we could continue implememtation tohave a demo application ready as soon as possible." I'll try to think about this and write you later if I have more ideas. > Please give us as detailed info as possible, so we could continue > implememtation to have a demo application ready as soon as possible. > Thank you. You're right, I forgot something: There should be a function "Display sessions" at the home server, where the user can see the list of all remote servers where he has sessions open at this time. This list comes as known by the home server at this time, without requiring any further requests(I would say, in the session variablesin the home server but it can be not goodfor the case of a request that comes from a remote server and not from theuser directly.So, instead of session variables it can be in a database or I don't knowwhere). In front of each server name there is a checkbox, and below there is a button "Logout from checked servers". Then, for checked servers, a logout request is sent to those hosts, killing the user's sessions there.Conversely, every time the user is at a remoteserver and logs out from there, the info is sent to the home server to update his list of open sessions. Is all that possible ? Well, sorry, in what I wrote you there was two ideas about logout which were not consistent with each other.One was about timeout, the other was aboutglobal logout. The question is: if timeout is something globally defined and if the list of open sessions is centrally registered, then logically the timeout should be centrally measured and when reached, the logout should be centrally decided and sent towards all existing sessions to close them. For this, it is possible to measure the timeout as you said, by a checklogin request from the remote server to the home server. But this fuction should not serve to check the login but only to update the last activity date (so it can be a "post"). Therefore it can be done just after the remote server answers to the user, and not before, in order to show faster the displayto the user. Only at the time when the timeout is reached, the home server should wake up by itself and warn all the others (from the list of open sessions ofthe user) that the sessions are finished. The problem is: ifever the home server got down, the other session would stay open. So what do you think is best: like this or with some local timeout like I said, or request of answer by remote servers ? One more idea: Hello. I think about the following idea: On top of visited pages there should be a toolbar of links like: - Bookmark this page (when done this link becomes inactive or "bookmarked" or "delete bookmark" -it may have been bookmarked already but the link "bookmarkthis page" still appears becausethis fact is unknown here, it's not a problem) - Open navigation board (in new window or popup, or refresh the existing one) - Close this session In the navigation board in popup (from the home server) there would be access to the list of open sessions(that could be closed as I said), the list ofbookmarks (well I would have to think about the display details as there may be too many bookmarks),a possibilityof general logout or access the entry page of the home account Hello. I can already let you know about the next works to do after multi site login,webmail and invitations. First, there will be the personal web pages, that I already mentionned. For this I think about including in the same toolbar I told you (with "bookmark this page",navigation and logout) an "Author" link, by which it will bepossible to access information on theauthor and send him a message. Then there will be the dating part. It will make use of the personal web pages part.The main work there will be to make the registration of all personalparameters and search criteria (I wrote a listof such parameters but am open to moresuggestions). I have a contact with someone who has already an interesting piece of software that hasan admin board with possibility to create new parameters and searchcriteria in manyformats, using some metadata, without affecting the database (amodification of parameters or of their naturecan be applied over an existing userdatabase !). He is ready to sell it to me. He gave me access to a test implementation of his software (I can forward to you the address). I tried a little, but I did not very well understand this admin board. From this I would add complexity in the search criteria by including a system of points to evaluate the correspondance in a continuous way. I will tell you more specifications when you will be ready. |
|||
Sam 12 février 2005 |
webmailspecification. Webmail-specification Only registered and authorised users can use webmail. Realization: PHP and MySQL Now we have to receive two main questions: What is webmail? Is it the interface between user and your mail-server? We right? Itincludes receiving, processing and dispatch of mail with the help of your server. Sowe have to create an interface between user and mail-server. In that case we need toknow which kind of software you are going to use, which drive protocols, and preferably your server configuration, situation of mailboxes and other informationon this topic. What is invitation sistem? Could you send us all information about it? What shouldwe add to users’ email? Write us an example of text and link, please. User abilities: - ability to look through mailboxes - ability to compose email - ability to attach file to the composed email - ability to send email to other users and to free adress - multi language interface - ability to read email inside mailboxes - ability to delete email (one or all) - ability to replace email to anoter mailbox (one or all) - ability to answer the received mail - ability to foward mail to another user - ability to use sessions while working with webmail Invitation link and text will be added automatically to all mail composed by user. ------- [my reply:] Sorry for my impatience. It's OK now. About webmail: I think you understand well, but sorry if I'm not sure. To be more sure, I'll express things in my terms. I would like to give people (anyone downloading the code of my project I will release on sourceforge)the means to install this code in relatively any (= in asignificant number of possibilities) hosting service (either shared or dedicated hosting), that offers an SSL connection a domain handling that can serve both for http and for an illimited number of email addresses. Such a person that install the code, let's call him a super-user, that is possibly a user from the viewpoint of the provider if in shared hosting, but admin from the viewpoint of users of the new network. Each such installation would handle many user accounts (so, the super-user that pays for the hosting offers himself accounts for the users of my network).The emails received and sent will be handled by the code of my project.For example, by the sendmail function of php; I don't know how php code or whatever can handle the receiving of emails.I mean that my code would give users thepossibility to send emails, and also to read emails received at pseudo@domain.com, where "pseudo" is a pseudo of the user. Thus I need an installable code by which emails received by the server would be readable by the respective users when they log in to their account.I mean, I don't want to add the constraint to oblige users to log in oncemore somewhere. They are logged in to their account, they access the different functions of the project, and among them, they can display their received mails. Probably such code already exists. I'm commonly user of squirrelmail and imp, and I know they are free softwares.I know it is allowed to take free softwareand integrate it in other free software provided you indicate the source.So the problem is to do the integrationinside a larger project. What I ask is to find one of the cheapest ways of doing this work, even if does not give all the powerful options of imp or squirrelmail.In my project, webmailwill not be the most important way of private communication. Communication between users of the network will generally not happen through webmail but through private forums.Webmail is necessary only to allow forcommunication between members and non-members. "In that case we need to know which kind of software you are going to use, which drive protocols, preferably your server configuration"I beg your pardon ? Idon't know about technical details, I'm not expert in protocols. Please explain the possibilities among which I would choose.And you,do you have an idea on the question ? What system would you want for your convenience if your internet communication was based on such an account in a network with good communication possibilities inside the network but where private communication with the outside of the network would be based on this webmail ? (let's not try to make any mailing list with the outside, but simple one-to-one communication) Your list of function looks good. So it is just as usual webmail. I hope that by being usual it makes easy the programming work of integrating this (as a "copy-paste" of existing programs or something like this). Tell me if it makes this programming really easier this way. If not (that is, if you have to re-do everything in details), then I would consider inventing something.The only thing new here is integrating the system of pseudos. That is, bythe same login one can use different pseudos that are email addresses (for each pseudo the user has the choice in his list of pseudos configuration, whether it is a valid email address or not), and therefore read and write under any of these pseudos.For example (an idea of how to handle this): for each ofhis pseudo that is an email address, it is a different inbox and a different link to the compose message page, which would carry this pseudos.Or: all messages could be mixedin the same boxes whatever the pseudo but it would be nice if the compose message page offers a menu to choose which pseudo to use as sender, while, when replying to a message, the default pseudo (the one selected if we don't modify the selection) to be sender is the one receiver of the message to which we are replying. What would be easiest to program ? I don't understand well your last point: "ability to use sessions while working with webmail"The relation with the inter-site login is this one: webmail isworking only in the home server of the user, not in any secondary session at remote hosts. (I told you: each user has an account at only one server, his home server. The webmail requires an account, so it is at the home server).The session at the home account is the same used by webmail. "Invitation link and text will be added automatically to all mail composed by user." I thought of having a checkbox while composing a message to decide whether to add an invitation or not. Invitation text has the difficulty of possibly choosing another language. Link should be with a code to be used for registration only once (possibly sending the same code for re-inviting the same user if he did not use it ?) and take record of the relation inviter-invited. Thank you. Hello. How are you with your work ? You did not answer concerning symmetric keys: should they be changed regularly and why ?Thanks. [by Frozen:] Hello! Sorry for such a delay - lots of things are going around right now -). What can I say: beta version of GLS is almost ready, but we have some issues todiscuss. Fist of all - I insist that we send "checkLogin" function from every page that needsauthorization. Why? 'Couse of the following reasons: 1. Imagine that user has performed Global log off. Than he clicks on a link in someopened window to a site where he has already been authorized. Without "checkLogin"we will not be able to track users status in that case. 2. "checkLogin" not only checks if user is logged in on home site - it also updatesuser's last active time, so that we keep track that his "global" session is notexpired (by saying "global" I mean that it is all session on all sites that users iscurrently is logged in. If all this sessions expire - global session will expire anduser will have to relogin). 3. So as you can see our "checkLogin" works as synchronization mechanism betweendifferent hosts - thats why it is so important. About traffic gain that troubles you: this function only sends login as a parameter(that is for now, maybe this functionality will be extended later is we need it).Now the cost of traffic that is this function "eats" is so minimal, I can assure you- this is not the point for nervousness. 50-100 bytes more with every request - thata fair price for functionality we are proposing. Another question. For through-site navigation we will use packets in xml format (so called SOAP technology). The reasons for this are: 1. It is easier to implement SOAP messaging with STL than standart request-responsearchitecture. 2. Packets in XML format can be easily coded using our PGP coding (which we willdiscuss a little later). 3. This is simply the only suitable solution we have found - all other technicscannot give us all developing power we require. If you have other propsitions we are looking forward to hear them. Symmetric keys. I think that yes, they should be changed regularly, simple because of the securityreasons. Per day changes - yes I agree this is a little too much - but perhaps oncea month or a week is required. As I mentioned above we will discuss PGP coding whenfirst beta will be ready. What we have for now: Almost complete really extensible login engine, that will not only support PGP, butalmost everything you would like. For now we are not using pseudos - we haventaggreed upon this question with another developers team yet - but changing few linesof code will add this functionality painlessly. As I mentioned in my first letters - we are developing GLS in Java. What languagesare other teams using? About my phone - it is hard to cath me on phone now -( I am moving to other appartment and for I'm almost like on isolated island. I hope things will settledown in a week or so, and we could discuss our problems more precisely. Thanx for your patience, Vadim [my reply:] > Fist of all - I insist that we send "checkLogin" function from every > page that needs authorization. Why? 'Couse of the following reasons: I told you the idea to have something like this, but to post to the home site AFTER replying to the user. And not to check if session is active (of course it is, else a logout request would have already been received) but just to update the last active time. > 1. Imagine that user has performed Global log off. Than he clicks on a > link in some opened window to a site where he has already been > authorized. Without "checkLogin" we will not be able to track users > status in that case. In my idea, if Global log off has been performed then the home site would have sent the request to all sites with an open session to end this session, so when the user clicks, the access is refused.However I don't know if itwould be difficult to implement. Is it ? > 2. "checkLogin" not only checks if user is logged > in on home site - it also updates user's last active time, so that we > keep track that his "global" session is not expired (by saying "global" > I mean that it is all session on all sites that users is currently is > logged in. If all this sessions expire - global session will expire and > user will have to relogin). 3. So as you can see our "checkLogin" works > as synchronization mechanism between different hosts - thats why it is > so important. About traffic gain that troubles you: this function only > sends login as a parameter (that is for now, maybe this functionality > will be extended later is we need it). Now the cost of traffic that is > this function "eats" is so minimal, I can assure you - this is not the > point for nervousness. 50-100 bytes more with every request - that a > fair price for functionality we are proposing. Yes but I'm not considering the waste of machine time, but the waste of user's time when he clicks on a links and he has to wait before display. If the signal is posted after replying to the request to the user, then it is good for the user. Moreover, a signal to post the activity notification is more economical than a request for information that requires the home site to reply. > Another question. > For through-site navigation we will use packets in xml format (so > called SOAP technology). The reasons for this are: 1. It is easier to > implement SOAP messaging with STL than standart request-response > architecture. 2. Packets in XML format can be easily coded using our > PGP coding (which we will discuss a little later). 3. This is simply > the only suitable solution we have found - all other technics cannot > give us all developing power we require. If you have other propsitions > we are looking forward to hear them. No I have not, thank you, I trust your knowledge in this regard. > What we have for now: > Almost complete really extensible login engine, that will not only > support PGP, but almost everything you would like. For now we are not > using pseudos - we havent aggreed upon this question with another > developers team yet - but changing few lines of code will add this > functionality painlessly. All right (...) Hello. Concerning the dating part of the project, I mentioned to the programmer working on profiles that they would be posted between sites. He answered the below comment. I then answered that the networking problems were not his business, I would care about that. More precisely, I think it is enough to ensure that profiles posted are authentified as coming from the network, as machines that would post parasitical profileswould be banned. -------- Hi there, > Question: I wonder if it would be better for privacy that the profiles > posted between sites be crypted usinga symmetric key that will exist in the network as the "Frozen Team" is > implementing. Is it something difficult ? You know i think it's too hard for implementation and it is not necessary. When data have to be posted from one site to another it'll work on sockets technology. And when we start to talk about remoute profiles posting to another sites: send me the list of the sites (where you need to post profiles). Each site have own security system which work to STOP posting by any BOTs (robots) it's really hard work to implement the remote profiles posting . To make it's real i have to learn security system of each site (where we have to submit profile)and implement program posting for each of the site one by one... This algorithms cost much more than $250 ... Regards, Evgeniy [my next reply to frozen:] > Hi, > I'm not quite sure what you mean. You don't want PGP coding now, > instead of it we should just check was a request sent from inside our > network? Checking this is the most important. If it is not a problem (for cpu resources...) to add encryption, then let's do it also. > I havent looked in to details bu I dont think that implementing PGP > coding is such a difficult problem, 'cause all algorithms are already > written. But if you say so... I don't say, I ask questions. Thanks. Anyway it's not any urgent question for now. Regards, Sylvain >As I metioned before GLS written in such manner to be included in ANY >other web>application. Good. >Just imagine: user logs in at home site ant wants to >check hist mail. So he clicks a Bookmark (i.e. "Check new mail") and is >automatically logged in into his Webmail account All right. I did not see this as a really useful possibility (webmail at the home site should be enough) but why not. >For GLS there is no difference at >what site to perform authorization.As far as I understand this would be more >preferred solution for us. What do you think about it? Please give me >your point of>view. You mean it is the same kind of authentication for home users and foreigh users ?Okay, provided that any application at a site has the possibility to knowwhether the user has hishome account here or is coming from elsewhere and where. >Well lets discuss this a bit later when GLS will be finally tested and >approved, ok? Okay. >1. Will there be the only mail server for the whole system or there will >be "one>host-one main server"? In out opinion one (or several, but not >one-to-one) mail>server is more prefferrable. What I want is to let each server have all functions. That is, its own set of home accounts from which users can be authentified everywhere. I told you that what I want to do is a new Internet, with globally billions of users with their home accounts distributed into many servers (thousands of users per server). >2. We would like to know more info about mail server you are using: what >protocol>(POP3, IMAP), information about port which you are using. All in >all we need>complete information about your mail server. I don't have any mail server yet. Hosting is yet to be found or created. It would be good if it was relatively easy for people to install themselves the program on hostings not hard to be found.So you have the choice. If Iunderstood well, IMAP is better as it offers richer possibilities of operations than POP3.So if it does not make things harder, Ithink that we should choose IMAP. Hello. In the connection you make between GLS and webmail, what do you do with pseudos ? The interest I saw with webmail at the home site of the user is that it could handle several pseudos, but at remote site it can handle only one pseudo. (end of relevant messages) |
|||
Lun 21 février 2005 | You cannot send automatic logging in into all the hosts because the system must be designed to work for a network of hundreds of thousands hosts and: - It would be too much useless traffic - the information of when the user logs in should not be published everywhere this way. So logging in to the home site will not directly produce any request to other sites, but only later when needed. So the "global log in" will exist as something integrated into the bookmarks system, in the following way. In home host of the user (for example in the session variables) there is a list of all sites B where the user has an open session. The user can display this list and decide to end one of these sessions (this will send a logout request from home host to remote host - unless it is a request by the user to the remote host that will inform back the home host ?). I imagine a bookmark from a host A (user's home site) to a host B as the following. It is a link of request to the host A, that (as the user is logged in), if the user has not yet a session in B, A will compute and send back to the user a redirection to the host B containing the crypted list (xml ?) of data: - Pseudo used - Prefered language - Time of request (the present time of clicking the link and producing this data)- What page one wants to access (for example, a personal web page, a forum, a thread in a forum)- (and for later, possibly other info) So, the host B receiving the request from the user will decrypt this data (knowing from the request that it comes from A, and deducing from it what symmetric key to use for decryption) and, if the time is checked to be the present time (with no more than a few seconds difference): Open a session with session variables set: - what host A it is from - Pseudo - Prefered language Then pass the execution the PHP program that controls the page one wants to access (program of forum or PWP), passing to it the detailed id of that wanted page. If the user already has a session in B, the bookmark will only contain the info of what page to access. Concerning bookmarks: there is a "list of bookmarks", but other programs that will need to produce links to remote hosts in an authenticated way will also have their links working this way, calling the GLS system as above |
|||
Mar 22 février 2005 |
- GLS spec. - idea of sending a signal to all peer sites saying the user has logged in ==> no sense. The problem is not to know whether a user is on the web or not but to identify securely wich data is coming from him and not from elsewhere. - improve security of the system by crypting all links internal to every site. - cannot figure out how a link from a page of the home site directly to a remote host without being first a request to the home site that redirects, would not take the risk to be intercepted by a spy and later reused after SSL decryption (that is hard but as I heard not totally impossible, at least it would take time) unless the condition to be instantly used after creation (with time included in crypted data) is put. In a link to a remote site, the link is not instantly used after it appears on the screen so this condition cannot be put. |
|||
Ven 25 février 2005 |
- GLS understanding - trustedforum.html updated - forum ==> see the invitation line (invite someone else to the forum). ==> page of list of threads. ==> forum info page ---> add the invitation line somewhere else than inside threads, probably in the "forum info" page. - GLS |
|||
Sam 26 février 2005 |
php 5 innovations: handling of
XML |
|||
Dim 27
février 2005 |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ An updated GLS specification is attahced. q: What should happen when the user clicks "logout" somewhere at a foreign host? I see two cases: 1. Close a session to this host only 2. Close a session to this host and send a request to the user's home host to close all opened sessions. What if ask the user of it every time he clicks the link? --- Now we think of starting implementing dating system as a question of format of requests between servers is generally solved: GLS will contain a library providing functions which get ordinary PHP variables (arrays and so on), encrypt them with a public PGP key, form XML and send to the remote host, and then get an answer and analyse it and return a response. --- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ An updated dating specification of Datings is attached. I've changed: #00001.4 (ask for advices) #00003.1 (choose parameters to display in the list of matches) #00005 (list of twofold selected matches). |
|||
Lun 28
février 2005 |
- dating: the object of the info page is to display the parameters of that person (with the details for common penalties data but not other criteria). - GLS: things should be managed so that user@hostA 's request (crypted info) to access hostB should not be misused by the user as if he was user@hostB accessing remote hostA. For example, to do this, let the key be different from hostA to hostB than from hostB to hostA, or let "hostB" be among info. What do you think of the idea to name hosts by new names for use and display in our network instead of using their domain names ? ---------------------------- http://freelancewebprogramming.com/projectdetails.php?id=13528 ---------------------------- Project Description Suppose we have a given list of independent web hosts located at different places, each accessible by a different domain, and that agree for the following. Suppose each host has a pgp key, and each has the list of public keys of all other hosts. So we need a database to list those keys. We do not consider here the problem of how these data will be entered (let us enter them by hand). Suppose each host handles its own list of user accounts. What I need is a system by which, once logged in to his own host G, a user can visit any other host H and be authentified there as "user with name xx and parameters yy from host G" (where name and parameters are whatever the host H decides to communicate). More precisely, here is how things should happen: In the site H there are a number of possible pages to visit, say, URLs with parameters. Each user will have on his board at G, a list of his own bookmarks to some of these addresses in different sites (some in H, some in other H'...). The first feature I need is that this list of bookmarks can be extended, either by the user copying the address in his account, or, if the host H itself decides to send this bookmark to a given user of G. In particular, when the user of G will be already authentified this way (described below) to a given page in H, he browses H further, finds another page and wants to bookmark it, so clicks "bookmark this page" in H, so H posts to G the request to add this page to the user's bookmarks. The second feature I need is that, when the user clicks on one of these bookmarks that appears on his board at G to a page in some host H, then a new window opens that accesses to that address in H while opening there a session where the user is known by H as user of G with given parameters. Here is a suggestion of a possible procedure to make this: Before all this, at the creation or update of the network, for each pair of hosts a symmetric key is created, to be available for operations like this. The parameters to access H will be crypted by G using this symmetric key. This crypted info will be included in the link to H. I imagine two ways: either the bookmarks page is itself made of such links to other sites, so that the request will be direct; or it is made of links to G that request G to produce this crypted info for H and make the redirection. I imagine the second solution may be preferred for security reasons, to better control the set of sessions of the user at other host from his board at G, and allow for a "general logout" operation at G that requests all other hosts to cancel their sessions (unless with the first solution H posts to G the indication of session). I suppose that SSL connections everywhere are required I imagine that H will know who is G by the fact the previous address is included in the request (is it ?), else the identity of G can be included in the request. I'm not an expert in computers, so I'm not sure the proposed solution is the best. Else, please explain. I wonder if the IP can be taken as an authentication criteria (because if the user has a dynamic IP it may not work). I wonder about the possibility for third parties to spy the crypted info and use it to request authentication instead of the legitimate user. How to avoid this ? Is including the IP and/or the date and time of the request in the crypted info sufficient ? Also, by the possibility to cancel a session in H by a request to G that will forward the logout request to H ? I have wondered if a direct request from G to H can be useful but it seems not so for this authentication operation. This project can be done in any language provided that it is secure, efficient, based on free software, and interfaces well with php pages. |
|||
Mer 2 mars 2005 |
- replace redirections I see the following hole, "The link leads directly to the foreign server and has some unique id attached. This id contains something like:" What do you mean by "this id" ? Do you mean it is the list of the following data ? Consider the following scenario. Some user U is logged it to his home site A. Some hacker H does not know about it but bets he may be. H wants to acces site B pretending to be U. For that, he produces the id containing A's global id in the system, id of U which is used and sends this request to B. Then, when B connects to A, then A answers that U is logged in. So this session with H is accepted.U does not pay attention to this, and lets this session at B open. So, adding a random number would be absolutely necessary to make your idea secure. I had already thought about this scenario before, but then thought that the senario I proposed to you would be more simple, not needing a random number, and avoiding the need for a direct connection between servers . (or would you add a connection between servers to make a new symmetric key ?) Your idea will force you to handle a table of random numbers in the database. I think it will not be very simple. Somehow, I tought that the crypted data plays the role of random numbers with no need to make a table of them; and every page displayed to the user would be loaded with many hidden random numbers with your proposition, not with mine. Do you mean that accessing a crypted data by a symmetric key gives a chance to find out what this symmetric key is ? "the user doesn’t access anything that depends on (computed on the base of) the server’s private (and public) keys" ? I meant it would only depend on symmetric key between servers. For the hacking problem of one server: I do not see the difference between getting the private key and controlling the server completely.If a hacker can get the private key, he can also access users'passwords, therefore log in instead of users and access remote servers in normal mode by first loggin in as user.What can he do more to remote hosts with the private key, that he cannot do by simply loggin in as user and using GLS in normal way ? ----------------------------------------------------------- |
|||
Ven 11 mars 2005 |
- the possibility to invite a new user without email, from the account of an existing user - The possiblity for users to see the problems they are concerned with: the problems affected to him personnally, and for each problem which passes through him, who is the next user un the chain (that he invited) ; with the comment. ==> for each person he invited, he can see how many corresponding problems, and by clicking, can display the list of associated comments. |
|||
Lun 14 mars 2005 |
-forum : it works slowly. |
|||
Jeu 17 mars 2005 |
- webmail |
|||
Ven 18 mars 2005 |
- Datings as that spec. - GLS security issues Remark 1: Forum works slowly in a reason of a low priority of subdomains in our domain. Remark 2: We have another one programmer ready to start working with WebMail and Invitations. no webmail spec |
|||
Dim 20 mars 2005 |
About webmail and invitations: Let the admin the possibility to forbid a user from making any more invitations of new users. |
|||
Mer 30 mars 2005 |
http://tforum.php.by - I read "Pubilc forums_forums" More remarks about forums system: I created a forum, and in "edit forum rights" I have no link to go back to the forum, and the back button of the browser does not do the trick. The "move to folder" should keep displaying the same box and not the box the forum is moved to. When a forum is created, the creator should be subscribed to the forum, until he unsubscribes. About dating parameters: I just start looking. I see about languages the question is repeated for a given list of languages. It is not good. To explain in more details, there are 3 questions. 1) "parameter" : first, the user selects some languages from a given list of languages. Then, another display shows for each of language, what is your ability: as in your column "choice" (or any logically equivalent display). 2) other "parameter": willingness to learn the other's language": 0/1/2 3) "criteria": what badness for each quality of conversation (this question does not mention any particular language) I will review more things next. |
|||
Mer 30 mars 2005 |
for nationality - European - African - ... - link "details" that will replace it by the list of all countries of that continent, ( with value for the continent). |
|||
Mer 6 avril 2005 |
security worries |
|||
Sam 9 avril 2005 |
- got the message in my email spoirier@lautre.net - pseudo of inviter should not appear in clear in the URL. It is bad for security: imagine one wrote this url with another pseudo... So it should be a random number instead, stored in database with pseudo of inviter and email address of invited person (or id from address book) so that the inviter will see it in his contacts list. |
|||
Lun 11 avril 2005 |
- criteria * "A little but I can stop" fits more for smoking than for drinking. I thought of including "trying to quit" for smoking status. * can I edit myself some file of list of parameters and their different options instead of asking you to make any modification I have in mind ? * I did not see the option to "ask for advice" or not: how to stop asking for advice ? OK, I did not think about separating the selected from the selected+. I only see display of parameters, not yet possibility to modify it. - trees (ethnicity...) - geographical criteria. |
|||
Mer 13 avril 2005 |
analysis of database another time. -OK: separate the selected from the selected+ - display of parameters, not yet possibility to modify it. ---> Why not? You first (for the very first time) enter the parameters so then they are stored. 'Minus' sign becomes 'Plus' near the corresponding menu point. But you still can click the link and view your parameters. All the fields are visible but disabled for editing. If you anyway want to edit them, you click the button at the bottom of the page and the fields become enabled (editable). To store changes, you click "ok". - button to enable editing. instead of a whole line for "activate account" in the menu, make a link "account status" which would give control of the following actions (because they are not often used, putting them together in the menu is ok): - Ask for advice or not - Activate account/inactivate account. - Send account - Set/modify PWP address(es) (just as an URL now, until the PWP system is made). Note: the "send account" should send with each server the list of profile id in the other server that matched with user, no matter their status, in order for the other server to not re-test the profile with those matches. It does not matter to recompute what has been computed and found negative (not a good match) because the profiles details may have changed since so the result may become positive, but it matters to not make users review profiles again uselessly (if one has been trashed, he is trashed and remains so). In trash, the display is by order of trashing date, from most recent to oldest. |
|||
4
may 2005 |
======= PWP ======= 1. Should I write a real-time HTML-redactor allow user to create his PWP in real-time mode or an interface to allow user to upload his finished web-page from computer using https or ftp. 2. I offer to store site content not in folder called "/pseudo/" but to keep it in a database. It will be more useful according to the security. ==================== |
|||
4
may 2005 |
======= PWP ======= 1. real-time HTML-redactor ==> user create his PWP in real-time mode ==> an interface to allow user to upload his finished web-page from computer using https or ftp. * better a real-time HTML-redactor ===> security + ===> page to be re-processed for headers and active links. ==> re-use existing wiki systems, splitting its functionnalities between - text formatting on the one hand - history - user accounts and editing rights * diversity of text formatting systems, that can be assembled with any of various contexts: personal pages, wikis and forums. * In further development, so, we would include the other aspect of wiki: have each page be editable by several users according to a system of rights, with history to check what has been done by everybody. * Several kinds of pages: some personal (to be edited by only one person); other collaborative, with tables of editing rights (or denials) and history. * The system of rights would be similar to the one of forums; system of handling rights, usable for forums as well as for wikis. |
|||
13
may 2005 |
* PWP * server can cope with thousands of users |
|||
Mer 1 juin 2005 |
-PWP.: organized into groups
where in each group are files with the same rights. For example we can
make directories like http://domain.com/directory/ and in each
directory are files with the same rights.Unless: I wonder: maybe a
group should be of the pages with same editing rights, but reading rights can differ from a page to another. So: first the user creates a group with a given rights system. The simplest, that can be the only one in the short term and it will be OK for now, is that it is personal: only one person can edit it. Another one is to re-use the system of forum rights for this task: there will be rights to read and edit as there was right to read and write. Then the question is to have one or several methods of text editing. One method would be the upload of an html file, in hope that there are not unsecure functionalities. Another would be bare text but I’m not sure it is interesting enough.But I think anyway we should re-use much of what already exists as wiki systems. Are there wikis with included images ? If not, we should add the possibility of images.Wiki systems include text editing methods, and also a system of headers with history. It is good to have headers and history, we will take them and complete the headers (and links) to fit with our GLS and bookmarks system. For the case of a personal page, the headers must contain the pseudo of author. - After that, it may be interesting to have the function to convert pages from a format to another (between html and wiki-type conventions, for example). - In the future--> to have an online TeX compiler: to edit a TeX file in my account from an internet cafe, save it to server, then run pdftex on server and get the resulting pdf file... |
|||
Ven 15 juillet 2005 |
- GLS http://tforum1.php.by/gls http://tforum2.php.by/gls. http://tforumX.php.by/gls you are immediately redirected to http://tforumX.php.by. SO now after logging in you have to go to http://tforumX.php.by/gls by hand. You may pay attention on "Bookmarks", "Default bookmarks" and "Congiguration"-"Common settings". - difference between bookmarks and default bookmarks ? - Every time you have to choose details concerning the result for the user that are not obvious, please tell me so that I can tell if it fits or not.What is precisely the role of the /gls/ directory ? |
|||
2-Dec-2005 |
1) dating_sped04.rtf from 27.02.2005 2) GLS_spec_1.04.doc from 02.05.2005 3) spec2.todo.doc from 18.08.2004 4) specification.doc from 18.08.2004 * Email invitation * GLS integration system |
|||
3-Dec-2005 |
* dating_sped04.rtf : february
2005 * GLS_spec_1.04.doc : may 2005 * spec2.todo.doc : august 2004 * specification.doc : august 2004 |
|||
http://spoirier.lautre.net/tf-todo.htm |
||||
20-Dec-2005 |
email users invited only with RW
rights |
|||
manage comments for remote users
==> put it in "forum invitation table", comment modification |
||||
the key for security is a random
number |
||||
mark message as read when it is
sent to some emails |
||||
XML - formatted and encrypted
data |
||||
sends : server host, language,
remote function name, arguments to function |
||||
access to remote host : bookmark, or links. OR communication between servers for other purposes |
||||
bookmarks links contains pseudo,
hostID, language, secret string |
||||
all communication encrypted (
through bookmark, or directly between servers) |
||||
session contains : pseudo,
userid,id,language ==> user ( pseudo, hostid) |
||||
21-Dec-2005 |
other users can not invite
emails to ADMIN rights email invited can post messages only if he has W rights |
|||
local users name pseudo(comment)
or pseudo@host |
||||
hosts have nicknames not similar
to domain names. |
||||
there is an info page of users :
click on pseudo leads to pseudo info page. for email users : info page says if it has invitation or not ( by you or by someonesels) |
||||
the link holds secret infos:
inviter, forumID, email rights |
||||
* |
encrypt useng private key and
send to remote host: all info crypted by symmetric keys and the keys were renewed regularly by PG. Symmetric keys ( crypting and signature) |
|||
if session is open ==>
requests contains url to remote host, no key verification required. |
||||
if user access server through
SSL, hide URL on internet and parameters? ==> money exchanged
to be stored? |
||||
UTF-8 : French keyboard for
letters |
||||
21-Dec-2005 |
URL
http://trust-forum.php.by/index.php?action=showthread&id=2 global list of thread for the forum ---> should be http://trust-forum.php.by/index.php?action=showthread&forum=1&id=2 local list of threads linked to the forum number |
|||
System robustness for 1000 users |
||||
10
Jan 2006 |
later add wikis and dating |
|||
10
Jan 2006 |
wikis |
|||
* |
i.XML ==> Encode
(function name and arguments) ii.Encrypt (public key) : openssl iii.Sign encrypted ( private key) : openssl ----> CPU evaluation ----> test with large number of users on 2 hosts clicking at same time |
|||
15
jan 2006 |
Re_trust-forum.msg | Re_trust-forum.msg |
|||
7
Feb 2006 |
Panel admin: forum_adminpanel_1.0.DOC | |||
8
Feb 2006 |
personal web pages to be updated
later |
|||
8
Feb 2006 |
admin panel |
|||
* |
==>????? ==> forum_adminpanel.doc ==> 01_info.doc |
|||
13
Feb 2006 |
admin panel documentation forum_adminpanel1.2.doc |
|||
* |
link
http://spoirier.lautre.net/tf-todo.htm didn't you ? ==> sets of doc sent : Specification.zip (0.03 MB), Spec2.Todo.zip (< 0.01 MB), GLSspec_1.04.zip (< 0.01 MB), Dating_Spec_04.zip (0.01 MB) |
|||
25
april 2006 |
http://spoirier.lautre.net/tf-todo.htm
? |
|||
25
april 2006 |
get at
http://spoirier.lautre.net/tf-todo.htm ? |
|||
Sam 3 juin 2006 |
- wiki |
|||
Jeu 17 août 2006 |
- personal web pages that
selected matches gave access to: URL (instead of a page stored in the system). |
|||
Lun
16 octobre 2006 |
16_10_2006_task.doc “edit” instead of “save-preview-post” only in edit form, only for read messages. Title should be one line high. To make message body little bit bigger. Check edit form (title and body) using next string: ²&é »’(-è_çà)=s”d”f<sdf>sdf. check user rights at operations: denies page (if not admin, not to see denies list); forum info (if not admin, not to see link to denies page); at “showfolder” page, invalid list of members of forum. to check compliance of http://trust-forum.php.by and http://tforum1.php.by, http://tforum2.php.by; to make a mechanism of distinguishing of previewed message in messages list (edit form is situated under the previewed message). check admin panel for display characters At pseudo info page, it could be possible to do 3 actions in one step: create private forum left a message there invite this user to this forum Translations. In translations page should be 3 points: 1) use translation 2) compare 2 translations 3) edit translation. translations could be public or private. public translations could be used by anybody, private translations could be used only by creator. Creating new version prompts new version number, but this number can be edited. |
|||
Jeu 9 novembre 2006 |
- thread paging (under construction), others... |