Re: [IPCop-devel] Language, API and other stuff

>1) There is a belief that a language was chosen - I for one do not hold that
>belief.

Python won the vote Mark set up, though Jack's not happy with the 
voting process.

Mark's too busy hacking and house-buying to even talk about it yet :-)

>2) About API and how that project is to be divided... That was going - but the
>conversion has been stopped for a few days.

Not sure if it stopped because y'all finally agreed, or got tired of 
arguing. :-)

I suspect the latter, unfortunately...

I think some things got hammered out, or at least some options were 
eliminated, but I don't think it's anything like complete nor 
stable...

Is anybody qualified (ie unbiased and knowledgable enough) to 
synopsize?...  My light-hearted attempt at synopsis was factually 
incorrect (sometimes on purpose for the sake of discussion) and very 
incomplete, partially because I don't understand half of this stuff...

The parts I do remember and understand (more or less):

There seem to be several different ideas as to how a user should be 
able to alter their firewall rules, ranging from color-coded systems 
to drag-n-drop to a basic big ol' type-in box for an easier way to 
type/edit rc.firewall.up through the web GUI instead of SSH/vi to... 
Actually, I don't think we have any two people agreeing on this one. 
Too many chiefs, not enough braves?

Somebody (me) even asked if we should really focus on rule-changing 
instead of improving the feature set, interface, etc since the number 
of users who need to tweak the rules post-configuration is relatively 
small and are usually knowledgeable enough to do it by hand.

There was a lot of discussion about where the right place for the 
"business logic" of the install/config GUI belonged:  Some think it 
should be all built into the XML tags with a "meta" 
screen-description language defined, others that the client should 
only know a few types of XML tags to present (akin to HTML's INPUT 
choices, roughly speaking)  Part of the argument is about how much 
data you want to transmit over XML/RPC, and part of it is about how 
"locked in" we want to be for look&feel of GUI.  Version control of 
GUI elements also fits in there.

Dividing up the work seems to be not even discussed, really.  Mark's 
"controversial" survey had more Python volunteers than the rest, so 
that was the basis for the decision.  That said, it's not impossible 
that all the Python voters are less-skilled or have less time or... 
Honestly, I think the *BOTTOM* line on language choice should be left 
up to whomever sits down to actually do the work.  So far, that 
mostly seems to be Mark.  The way I figure it, we should just use 
whatever he thinks is best, since he's done most of the coding so 
far...

Now if somebody sat down and did an XMLRPC GUI/server in COBOL and 
submitted it as a fait accompli... Well, okay, COBOL is perhaps a bad 
example :-)  Still, at this point, we've got a lot of talk, and not 
much coding.  And that's good :-)  But when the time comes to type... 
Well, he who does the typing, does the *real* nitty-gritty decisions, 
usually.  I bet that if I spent the next two weeks figuring all this 
XMLRPC junk out and submitted a PHP version all topped and tailed, 
they'd even take that. :-)  [Don't worry, ain't gonna happen.]

Perhaps it would be good to re-start the thread with some high-level questions:

What are the basic design goals of the XMLRPC system?
What do all users need to do all the time?
What features are "must have"?
What features are "good, but optional"?
What features are *NOT* "in"?
What kind visual elements can be used to represent those actions most 
clearly and cleanly to any idiot on the planet?

Much of this high-level stuff is probably on the Twiki, but I haven't 
looked at that page in awhile, and neither have the rest of us 
probably...  Hint, hint. :-)
-- 
Got Music? http://l-i-e.com/artists.htm