user interfaces for samba4 or samba3 configuration

Mingwang mingwxia at gmail.com
Wed Sep 6 01:30:59 GMT 2006


2006/9/4, derrell at samba.org <derrell at samba.org>:
> tridge at samba.org writes:
>
> > I'd also be interested in any comments you may have on developing with
> > Qooxdoo. I've been a bit disappointed at how little of the ui
> > mechanics is handled by Qooxdoo. I was rather hoping it might take
> > care of more of the details :)
>
> A qooxdoo (it's supposed to be all lower case) application can and is intended
> to handle the entire gui.  If allowed to, it will handle all of the details.
> The paradigm is different than developing a traditional web application:
> forget about style sheets, forget about html, pretend it's not a web
> application but is a local gui application.  Writing complete, really nice
> applications is made even easier with the 0.6 version of qooxdoo (which is
> not, I think, what Sree has been using) but the 0.5.x versions also have
> adequate capability for very nice applications.
>
> One big problem with doing things "right" (and resolving many of your
> described AJAX issues) is that ejs is too incomplete to implement JSON-RPC
> properly.  With JSON-RPC implemented in samba4, it would be really easy to
> make requests from the gui code to the core code in an asynchronous fashion,
> and have a gui akin to modern local applications.  Unfortunately, ejs is
> missing (according to their web site) such basic features as object and array
> literals.  Without these, implementing JSON-RPC would require writing parsers
> for the literals in javascript.
>
> I have two potential exercises to play with at the CIFS conference.  If there
> is interest from the samba4 team, I'd like to see if it's possible to allow
> replacing ejs with SpiderMonkey (the javascript engine used in Firefox).  I
> would hope to implement this in such a way that SpiderMonkey would be a
> drop-in replacement for ejs, i.e. the ejs functions already being
> auto-generated would be enhanced, if necessary, with context information
> required by SpiderMonkey user-added functions, but left in place so that ejs
> could still be used if desired.  (This makes the most sense, I think, at least
> until it is decided that SpiderMonkey can easily entirely replace ejs.)  In
> order to do this work, I will require some assistance with making the pidl (?)
> changes necessary to add SpiderMonkey context information to the generated
> javascript-enhancement user functions.  Once SpiderMonkey is in place and
> working, a much more elaborate gui could be developed much more easily.
>
> If the samba4 team is not interested in having me toy with adding
> SpiderMonkey, my other potential exercise for the conference is to begin
> playing with a qooxdoo application for samba3, for configuration.  If I
> understood correctly, there was a SOC project in samba3, adding a library for
> configuration.  (Is this true?)  If so, then adding PHP bindings to that

Speaking about this, the new configuration is based on old loadparm.c&
params.c,it has no RPC or other network related things,but get/set*()
API.
just to make things clear. :)

> library would allow qooxdoo's existing PHP JSON-RPC server to be used for
> configuring samba3.
>
> Please let me know if there's interest in either of these projects.
>
> Cheers,
>
> Derrell
>


-- 
Cheers,
Mingwang


More information about the samba-technical mailing list