Am Sonntag, 20. August 2006 07:38 schrieb Yannick Lecaillez: > Avi and i discussed about removing KEY_TYPE_DIR. Avi proposed to > split key type (regular, dir, link) from key value type (string, binary).
We should prove now to came on such things to a solution for everyone. I think to split this information is a very good idea. But the custom types (like self defined KDB_COLOR or sthg), should not be dependend if it is a string or binary. That means, that a user defining his own type system cannot brake sthg (e.g. that he defines it to be a Folder or link) > Key contain a mode_t access attribute yet, the idea is to use it for > store key type : regular (S_IFREG), directory (S_IFDIR), link (S_IFLNK). Is access the right word for it? > This way, the key->type attribute will contain only the value type > (STRING or BINARY). We were agree it was a great idea :-). I agree here too;) > That need lot > of modification into elektra but most will be, i think, transparent to > the user (i don't think that impose an API modification ?). This will > allow us to store value and comment into directory key. I think the problem in doing this is more backend related then the small (but existing) API changes. Thus there is only 1 backend really mature, should we risk to add a new feature? > Btw, that still a big change and we haven't released something for 3 > month. So the time is perhaps to a feature freeze and finish to debug > things which were done. About that, thanks to report any problem you're > still encountered while building elektra. I will do that! We should also concentrate on make check and on testing daemon and patches. thank you Markus Raab ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Registry-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/registry-list
