Re: Your mc efforts is a great job !!! [Warning]: Long
- From: Nikolai Bezroukov <speditor optonline net>
- To: mc-devel gnome org
- Cc: Pavel Roskin <proski gnu org>
- Subject: Re: Your mc efforts is a great job !!! [Warning]: Long
- Date: Wed, 29 Oct 2003 21:20:45 -0500
[Warning] Long, as I reiterated some points from the prev discussion.
Pavel Roskin wrote:
> I'm not sure you are talking about mcfs. mcfs doesn't allow you to
> execute any remote commands other than whatever is already
> supported by mcserver. That's the standard file operations supported
> plus a few goodies like chmod.
I do not know the details of the actual implementation, but IMHO the
idea itself is very elegant althouth slightly ahead of the codebase with
its hardwired hotkeys. It's better to be preserved and extended it to
the full functionality. We should not throw out the child with a water.
Your concerns about security might be slightly overstated, as IPsec, SSL
or similar secure or semi-secure channel can be used. Moreover on
switched networks that now prevail, the session is not that easy to
sniff, if switches are configured correctly and hardened against ARP
poisoning. For example in the 3COM switches (SuperStack II) enabling
"Port Security" on a port makes the switch remember the first MAC
address it receives and locks that MAC address to that port until
overridden by manual intervention. After that any hacker can hit the
wall with his head as long as he wish. Also any attempt to use ARP
poisoning in corp. environment usually trigger IDS.
Here I am discussing the general ("theoretical") value of client-server
mode for this type of managers. And it is in this lights I stated in
http://www.softpanorama.org/OFM/Ofm_04.shtml and I am still convinced
that mc client-server capabilities provides an important, pioneering
step in the right direction. If keystrokes are parameterized into a
"command language", not hardwired like in the current implementation,
then this client server model is very natural with the server
interpreting internal "command language" and client converting
keystrokes to the command stream and updating panels.
The key advantage is the unique powerful and very attractive blend of
FTP and telnet functionality in one interface. IMHO such a functionality
might constitute a new protocol, "a command line VNC", if you wish.
Probably equally important is the possibility of avoiding those
horrible "Alice in Wonderland" key binding problems that litter this
list. The server is immune to the host key bindings and you can use just
one client on, say, the most "mc-friendly" Linux flavor (RH8 with the
gnome-terminal 2.0.1-5 ;-) to administer all your servers. That
instantly makes mc much more appealing tool to the system administrators
who need to work with a lot of servers and might help to increase the
development resources by attracting new talented developers.
> I was confused by "VFS" meaning two different things on adjacent
> lines. I still don't know what NC5 XTree VFS is. I have never used NC5.
That's how I call "flat file VFS". As a PhD I have the responsibility to
obscure things by inventing new terms ;-). See also
http://www.softpanorama.org/OFM/Ofm_00.shtml. The book discuses several
implementations including NC5.
> > The idea is to have access to top and bottom directory in the
> > current panel (which of course depends of your sorting mode) via
> > As I said, I'm not aware of such key in mc.
It's actually not defined either in OFM1999 standard or in OFM2004
standard (see http://www.softpanorama.org/OFM/Ofm_08.shtml and
http://www.softpanorama.org/OFM/Ofm_09.shtml ). Here is what OFM1999 is
saying (sorry, it's slightly Windows-biased ;-) :
The hotkey assignment for sorting is optional. If the hotkey is
defined its action should correspond to the F9-(LR)-S sequence for
the current panel and display the same menu so that the proper order
can be selected with the second key from the menu. Alternatively,
Ctrl-F3, Ctrl-F4, Ctrl-F5, Ctrl-F6 and Ctrl-F7 can be used for
sorting by name, extension, modification time, size and unsorted,
correspondingly ("NETSU" order).
For Unix you need to add the ability to sort by sort by permissions,
owner and group. So the menu selection string became "NETSUPOG".
As for the hotkey, actually, how about Ctrl-A ? A very convenient
hotkey for a frequently used operation (and resorting of columns is
definitely very frequently used, at least by advanced users). Actually
you are in a better position to suggest a suitable hotkey as I do not
really understand all the tradeoffs of the Unix environment especially
the potential conflicts with Emacs/XEmacs (I use Vim/Gvim).
> > >>But it looks like the major architectural weakness of MC is the
> > >>absence of a build-in scripting language. There are rudimentary
> > >>attempts to invent some rudimentary scripting languages is some
> > >>of mc (for example in user menu), but they are just weak and
> > >>inconsistent attempts to solve a generic problem by inventing ad hoc
> > >>mini-languages for each case. Currently probably the best way to
> > >>script mc is to use a programmable keyboard (like EnduraPro/104
> > >>FOCUS FK-9200, or MCK-142) or use Expect.
> > >Again, it's something that needs to be implemented and maintained.
> > >is not enough manpower to maintain even the existing featured in a
> > >shape.
Very true, and that's my point too. Here I would like to reiterate some
points as we moved the discussion.
I consider your efforts to be really outstanding because you not only
managed to revitalize the development, but also stop the feature creep.
Without your efforts mc probably would scale down to version 4.35. IMHO
two of your recent decisions (1) to clean the code of GUI-related staff
and (2) Windows-port related staff were very timely.
Two things are now more or less clear:
- mc is in the stabilization phase and it's level of maturity is
- the development resources are very scarce and just keeping up
with the usual flow of bugs strains the resources.
That's why I think it make sense to bite the bullet and move this
"cleaning" strategy on a new level by using the capabilities of S-lang.
Adding S-lang and exposing relevant internal functions might took the
same amount of efforts as a regular cleaning of code that is needed
anyway, but with much better return on the investment. Iit gives you an
opportunity to concentrate on simplifying and refactoring the core
codebase by removing several ad hoc mini-languages invented in usual
hacker-style traditions. For example, the code implementing "user
extension predicates" and "user menu visibility predicates" are two
examples of mini-languages, implementations of which can instantly be
replaced with S-lang with no or very little effort.
Also the pool of people who can develop/polish scriptable parts is
bigger/deeper. That's a natural separation of labor that the current
development environment is lacking: you need to be a jack of all trades
and react to each and every hotkey problem (actually even in todays
situation several things from the dscussions can probably be added to
FAQ to cut the number of such issues). Assuming the core and scripting
part are separated you have a core team and the extension development
community like in Emacs. that's a more powerful combination and I
suspect that more people might be willing to help with the scripting,
but few would dig into the current C codebase.
>> That might be not that simple and there might be some savings.
>> For example slang interpreter may be easily embedded
>> into mc to make it extensible. And that provides an opportunity to
cut "feature creep"
>> that takes a lot of efforts to
>> maintain by implementing some features via macros.
> I'd rather go with something more suitable for writing anything from
syscalls to multi-dimension
> arrays. Also, it would be helpful if the language was specifically
designed to be embedded.
> I thing Perl or Guile will be fine, but I didn't research
> this question. Anyway, it's all in the far future.
True, but paradise is unachievable on the earth, you know :-). Something
is always missing. And that especially true about embeddable
languages. I mentioned S-lang because it might be the easiest to
implement. The library is used by mc already, so it's almost in.
Actually for system calls, S-lang's "intrinsic function" mechanism can
be used (see jed codebase). S-lang also has arrays and hashes, so it
looks more or less adequate for the purpose. But the most important
point is that it's already *almost in*.
Moreover S-lang usage in mc may provide stimulus for further improvement
of both the S-lang and its interpreter and thus lift some or all of the
current limitations/reservations. There also may be some kind of
cross-pollination / integration with jed, which is a much better editor
then cooledit , so this is actually not a one time tradeoff when you can
lose of win, but a dynamic situation, a potentially mutually beneficial
It is true that S-lang has its own warts and limitations, but please
understand that is such situation there is no best choice, only the
worst choice and this might be inaction. The truth is that even the
worst choice (let's say adopting bash ;-) is better than none: scripting
language is one of the few available avenues of addressing the feature
creep problem .
The other solution might be exposing API and introducing a FAR-style
plug-ins mechanism, although they have their own problems and having a
two dozens or more of them installed lead to "overcrowding of the
kitchen". But technically this is as simple as introducing plug-in menu
in addition to the user menu or option to call a plug-in in the user menu.
I would agree with your point that Perl might be a more "politically
correct" candidate due to its very wide appeal to system administrators.
It probably provides the best opportunity to enlarge the community of mc
developers and users. As the success of vim-Perl, myperl and plperl had
shown in VIM, MySQL and Postgress development communities, respectively,
any product that adopts Perl as a scripting language instantly enjoys
some additional share of developers and users.
Guile is essentially "TCL on steroids" or "TCLized Scheme" so, while
like Perl it is capable to separate the core development and extensions
development, the fact that it's Lisp-based means that it is does not has
the appeal of Perl and probably will be *less* appreciated by the
current userbase (outside hard-core Emacs hackers crowd). In this sense
it's equal to S-lang.
Both Perl and Guile are definitely more complex and labor-consuming
undertakings that adopting S-lang, so pro and contra issues need to be
weighted by resources available for any such implementation.
Anyway, the earlier the decision is made and the transition plan
outlined, the easier is to fight feature creep and clean the codebase.
As Emacs demonstrated to the world long ago, a scripting language
provides the natural separation of core functionality and user
extensions. Moreover some non-essential, but man-power hungry features
can be temporary suspended or even removed with the promise to be later
reincarnated in the form of scripts.
If the recent crisis, that you resolved by stepping in, is any
indication about the future, a large pure-C open-source implementation
like mc might not be sustainable due to the level of complexity and
those of them, which cannot not attract enough resources need either to
scale down of face the possibility of extinction. Just because the pool
of really knowledgeable C developers is shrinking and they are in fact
pretty close to becoming an endangered specie. We all like free lunch
but somebody needs to heat it even if the food is free ;-)
That's why making this decision and taking some steps now, when the mc
development is clearly revitalized because of your efforts is, in my
opinion, so important.
Dr. Nikolai Bezroukov
] [Thread Prev