On 30/11/2007, <b class="gmail_sendername">Mildred</b> <<a href="mailto:ml.mildred593@online.fr">ml.mildred593@online.fr</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>(I don't understand why my mailer decided to send this email privately<br>and not in the list, so I forward to you all)<br><br>Le Wed 28/11/2007 à 14:07 Henry Jen à écrit:<br>><br>> IMHO, the main issue is what data need to be included in such an
<br>> address book, i.e. the schema.<br>> As access method, many MUA today supports LDAP, maybe the protocol can<br>> be used as a shortcut to achieve this goal?<br>><br><br>It would require to have a LDAP server on a desktop machine. I don't
<br>think it is a good idea .... Maybe some settings in ~/.local/config<br>could be set to define a program to call to talk LDAP with it (using<br>standard I/O).<br><br>Maybe this can even be part of the .desktop files specification. This
<br>reminds me the previous post of Patrice Dumas "protocol/scheme entry<br>in .desktop?".<br><br>For example we could have many .desktop files that identifies local<br>LDAP servers that could be run on-demand by every program that needs
<br>the address book. And the default one is taken the same way the default<br>application for a MIME type is taken today.<br><br>But this would need to write some code I think. That is write a LDPA<br>server that could fit well on a desktop machine, and that can be
<br>launched on-demand very quickly and that uses standard IO instead of<br>TCP.<br><br><br>***<br>Or maybe something using dbus. That seems more suitable than some<br>protocol that is designed to work on a network. But I don't know how a
<br>dbus address book server could be launched on-demand.<br>***<br><br><br>> > Maybe my idea of a shared database is not really good, but I don't<br>> > see something else. If you have any ideas, please share.
<br>> ><br>> > Also, if a such standard exists, I didn't find it (and it is<br>> > obviously not applied), please give me pointers.<br>> ><br>><br>> As for format or schema, there are vCard, FOAF, and LDAP schema
<br>> defined from various sources. I am not sure if there is a dominate<br>> standard.<br>><br>> If we can get open source projects agree on a common set of schema,<br>> that would be a great achievement. :-)
<br><br>I think we need flexibility, otherwise some may not use the standard<br>(because they need this flexibility). I don't know how LDIF works but I<br>think that all these schemas share some common attributes (like name,
<br>email, ...) In my opinion, the best way would be to be able to do<br>conversions between schemas.<br><br>In fact I don't really know how LDIF works, so I may be totally wrong<br>here. I just want to say that the format used should be extensible so
<br>that any application could add an attribute to the database. For<br>example if a new communication protocol (like jabber for example) pops<br>out, the format should be extensible enough to allow the addresses of<br>this protocol to be added.
<br>At first, it may not be standard and every software would pick a<br>different name, but they should be able to converge back to a single<br>name if it is standardized. So I think that the non standard attributes<br>should be possible, but they should be placed in different namespace
<br>(like the X-* headers in e-mails or the -moz-/-khtml-/... attributes in<br>CSS)<br><br><br>...<br><br>I really want to see a standard emerging there. I can't stand anymore<br>the current situation where software can't talk with each other.
</blockquote><div><br>Both the Xesam ontology and Nepomuk ontologies define metadata structures that essentially maps an address book.<br><br>Combining this with the Xesam search and (upcoming) metadata storage APIs should give you an abstract DBUS interface to an addreess book for free. That is one of our goals at least.
<br><br>If you really want to put energy into this I strongly recommend looking at what Xesam and Nepomuk already provide (or will provide soon). I can assure you that defining a shared standard for such things is pretty far from trivial.
<br><br>If you want the gory details on the Xesam Contact ontology I suggest you talk to Evgeny, aka Phreedom on #strigi or #xesam on FreeNode IRC. He's the core maintainer of the Xesam onto and active in Nepomuk too.
<br><br>Cheers,<br>Mikkel<br></div><br></div>