[help-GIFT] RFC: MRML for adding/removing documents to GIFT

[Wolfgang Mueller]

Hi,
Henning is suggesting to add database updating functions to the GIFT. I would 
suggest thta both of us (and anyone who wants :-) ) to submit here what we 
imagine the functionality and the interface should be, and then choose one?

So, lets go:

We want to add documents to a *collection*, and not to an  
algorithm-collection combination. So this has to be handled by libMRML which 
needs to pass the information on to the feature extractors and indexers. So 
the add-document message would be:

<mrml session-id="44">
        <add-document collection-id="TSR500" 
location="http://some.url/haha.gif"; />
        <add-document collection-id="TSR500" 
location="http://some.url/haha.gif"; />
</mrml>

or alternatively

<mrml session-id="44">
        <add-document collection-id="TSR500"> 
                <document-list>
                        <document location="http://some.url/haha.gif"; />
                </document-list>
              </add-document>
</mrml>

same for remove-document

<mrml session-id="44">
        <remove-document collection-id="TSR500"> 
                <document-list>
                        <document location="http://some.url/haha.gif"; />
                </document-list>
              </remove-document>
</mrml>

of course maybe some changes in the names. Please suggest. 

This should already get us somewhere.

Oh yes, and what' with security?

 The idea is that we need some users and some authentification. A simple way 
of doing this is to ask for passwords on opening sessions, and to give out 
then a session ID that is random (using a good random number generator like 
/dev/rand). The good thing is, that we won't have to send around the password 
at each interaction.

Another way of authentification is to use local sockets and to find out the 
user id of the one on the other side. This is particularly useful for desktop 
use, as we don't need a password from the user, and still the stuff is secure 
except if the account itself is already insecure.

All this authentification business should be separated from the backend in a 
way that all the query engines just look at the gift-uid/gift-gid of the user 
(instead of looking directly at the credentials). gift-uid/gift-gid can be 
identical to the uid/gid of the user on the machine, but don't need to be, we 
should be free in the authentification methods we use.

Is anyone interested in implementing crypted MRML communication?

Of course, uid/gid implies rights management on the backend. I suggest 
writing a general rights management library for the GIFT that can be used by 
any index to filter results.

Cheers,
Wolfgang