Thank Markus for spend the time to answer my questions. I know by experience and write to you(in this mailing list) it takes a long time to write up email and reply and I appreciate it. Like you I spent allot of time think about how i should implement things but I feel you do a better job of doing so. If you want me to focus on anther area that would be better help please let me know where that would be and ill work on it instead(please remember i not that good). I'm all self taught I find work with cmake and git difficult and require much research on my part.
Am Sonntag, 20. Februar 2011 schrieb Joseph Stein:
>> The main reason I brought this up is I thought this problem where solved
>> and want to see (and help if possible :) )Elektra push forward >>samba
>> Elektrification again. I was thinking (you or me) should drop a line on
>> samba mailing list ask them if Elektra-8.0 is good enough or what else
>> should be change in order for them to except Elektrification
>>>>Elektra 0.8 must be released before such a step can be taken. >If you try to
>>>>elektrify Samba again that might help the 0.8 release.
Yea I realise that, this is what i was trying and hope to do ---> help git Elektra-8.0 released and samba elktrafied.
> The switch I'm talking about is passing Back-end info in a ******** c
> struct***(not a file or wizard, what i would like to do is to add a
> function to read configuration of back-end from app not from file or
> Elektra itself and mount it)
>
> in code it would look something like this
>
> struct BackendConfig
> {
> string Name; //the name of the backend
> string UserPaths; //A list of user path seperated by ; for backend to
> search for it config(user can over ride) string SysPaths; //A list of sys
> path seperated by ; for backend to search for it config(only
admin can
> overide ) string ListOfPlugins; //A list of plugin seperated by ; that this
> backend uses }
>
> and then in the Elektrifed app(will use samba as an example)
>
> BackendConfig MyBackend;
> MyBackend.Name="Samba" //the name of the Backend.
> MyBackend.UserPaths="~/.samba/smb.cfg"
> MyBackend.SysPaths="/etc/samba/smb.cfg;/etc/samba"
> MyBackend.plugin="default;resolver;etc"
>
> KDBRegisterBackend(MyBackend);
>
> KDBOpen()//bla ...
>
> The problem with you current approach IMHO if i understand the code right is
> the following and what i'm try to solve are.
>>The problem with your approach is that it will only work on >>UNIX platforms.
>>The resolver plugin is responsible to resolve the user and
>>system path. It
>>should not be hardcoded. The other problem is that an >>administrator may want
>>to change the plugins used.
Sorry I still see i have not given enough info (no mater how hard I try) in my prior post and causing much confusion.
None of these problem are of concern and have been already address in many api and the way I plan implementing are not a problem.
The first thing that I think is causing me the most problem is i thinking your are think I try to change you current way of doing things.
********I not trying to make my struct approach the only way to load a backend.*******
Note:
(I will never try to change your current approach it will only make me bang head with you and I don’t like doing that type of thing, I also think trying to change the way i person dose thing is unacceptable behavior. Trying to change someone way they do thing is like trying to change someone mind (not going to happen). IMHO it just causes people to not consider my ideas because they feel that i want to destroy there idea. No one like seeing there ideas destroyed it just human nature and the reason i try to avoid do so)
The idea here is give the application the ability to load a backend by default and optionally overridden latter on if the user choose to using your current method of loading a backend from elekra config(or my idea which i believe you support load from file).
when you say
>>The problem with your approach is that it will only work on >>UNIX platforms
I can only assume you mean because of hard coded path and administration problem (Is there more?) because the resolver plugin should be cross platform(every plugin going to have a file system correct me if i wrong)
This problem with hard code path has already been address by many api ( i think libxdg-basedir is used to git stander path in a cross plaform way,-- I could be wrong--, and is supposed to be one such api and would like to use in elktra but worry about License,-- it uses mit. I no nothing when is come down to legality and mixing License , and I have look into using libxdg-basedir because of that reason ) I only used them as an example because elktra dose not have api like libxdg-basedir
yet. My stuctor idea should read more like this
BackendConfig MyBackend;
MyBackend.Name="Samba" //the name of the Backend.
MyBackend.UserPaths=ElktraGetUserPath(“config”)
MyBackend.SysPaths=ElktraGetSysPath(“config”)
MyBackend.plugin="default;resolver;etc"
KDBRegisterDefaultBackend(MyBackend);
KDBOpen()//bla ...
IMHO Elktra should have the ability to find where it is supposed to put it's config.
) for application to use. Every program going to need to know how and where they should store there config an optionally change it using the stander locations.
As far as the administration problem I would like to mention again That I would like my registerBackend function which i should realy call registerDefaultBackend will only register a default backend wich can be overrind by kdb mount so this would not be a problem. What i trying to do here is give the application the ablity to create a default backend if they want and not restricted by elektra default backend(if we add a bunch of feature to it that are not need buy elekcified aplication it will create bloat) .
>>I am not sure how these statements connect to the samba >>problem.
>>With the method explained above it is however possible to use >>xml or any
yes but all that has to be compiled into elktra default backend which add bloat or at the very lease require recompiled for every backend(may-be not a problem)
>>special format but still provide the old out-of-the-box >>behaviour like it was
>>before electrification.
The reason i want to create such a structor and how it relate to the samba problem is in the back of my mind i was think about all reasons way samba might reject samba be elekicfied. I know i need to be careful of bloat ,orginaztion and make sure I keep everything staicly link in. Some of these i mention earlier I think try to put two much feature in one backend is problematic because it add two it size. I think it need to be customized pre applicatoin wich can be done buy recompile elktra pre apps(but should we rely require elktra to be recompile pe app?). I can see samba reject elektra because of bloat or lack of origination. I was just trying to make improvement to it, I'll admit I not highly organized so I'm not the best to do it.
>>Currently I am mostly working on Elektra's environment. But my >>freetime is
>>quite limited at the moment.
no problem here take you time I have the same problem and the reason i only post once a week normally.
>> it dose not check for -i at all
>Yes, "kdb mount" is not finished at the moment. -i is always >assumed because
>no other option exists at the moment.
sorry i did not mean this to sound so rude.
One last thing anther reason for my struct idea is I thought it
would look neater in code to have the application fill in what need for a
default backend which a user could export and change to his likings which my method provides.
I did not what samba require you to run kdb inport <backendName> </path/to/file/>
If you try it, please report if it works.
best regards
Markus
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. 
RSS Feed