Julien Gilli wrote: > That's right, i like the idea too. There are several ways to achieve > this goal. One is to write a contact list client layer which would > have plugins, one for each storage protocol (LDAP, HTTP, etc.). Then, > there are open questions like, what happens if the user wants to use > several protocols at once. Do we merge data from each plugin? > > Any input on this subject is more than welcome, so feel free to > discuss it further. > Thank you very much for your insightful comments. > > Regards, > -- > Julien Gilli
Hi! I don't like the idea of a plugin based contact list system too much. At least not of plugins for different protocols. It would probably end up the way that one plugin gets improved and new contact list features, that the others don't support... I think the client should define the features and the protocol plugins should just allow to retrieve the data. But maybe the contact list itself could be sort of a plugin so that the contact list plugin outlines the features and not the protocols. Ok now how to manage contact list? The client should have an option to add and remove phone/address books. Something like, you go to the options dialog and klick on the address book tab. Here you should see a list of all your address books; by default just one - the local one. Now you can remove existing address books, change the order and add new ones. We are going to add a new one. So we click the add button and a dialog box pops up. Here we have to specify the type of phone book we want to use. local, mySQL (eg. for company networks), phone book script ... the user should be able to add new options here via protocol plugins. Well lets say we want to use a local phone book. So we select local and are then asked to enter a name for that book. If we want, we could change the save directory. This should be enough for a local book. Let's try the book that directly accessed on a database server (e.g. MySQL). the only thing we have to do here is entereing the database server's ip and provide the databse username and password. The matching protocol should get the phonebook's name and it entries from the data tables. nice, but we are even more interested in the phone book script. That's the php script mentioned before. Some one had to upload it on his webspace before. He had to configure it via an webinterface, create the users or allow users to register on his site and setup their phone book. Here the user has to provide the address of the script and again username and password. once we created our phone books, we click ok and go back to the main window. If we click on phone books here, we see automatically the first phone book in the list. above it is a drop down menu that allows us to chose a different phone book. I don't think that there is any need to merge phone books. Why would someone use more than one? The only thing I can imagine is that someone might have a phone book from his company and a private one. Anyways I think if someone has contacts on different sources, he has a reason for that and probably want so have them separated. Oh another idea might be to extend the serach function by protocols allowing to -of course- search all the phone books AND optional search online phone books such as klicktel.de or dasoertliche.de for Germany... In my opionion the most important parts are: - the php phone book script should be accessible for erveryone, so that every body can set up his own phone book service. This could be advertised with privacy issues. Like no big company stores your contacts. Actually they never get your contacts. - this phone book script should be more an contact book. It should offer the possibility to store email addresses, phone numbers, notes about a contact, kinda like the local solution used in wengo right now. - the script should be accessible from the web with a browser and without wengo. That's something new with VOIP. Skype does not offer anything like that.... :) _______________________________________________ Wengophone-devel mailing list [email protected] http://dev.openwengo.com/mailman/listinfo/wengophone-devel
