Greetings and a General Cleanup

El Viernes, 3 de Noviembre de 2006 14:39, George Makrydakis
escribió:
> M.Canales.es wrote:
> > The new jhalfs code may be something totally
different, thus the
> > discussion is open to any one that would expose
thier point of view.
>
> Totally different. Does this mean that the C++ route is
acceptable? 

Is acceptable for the long-time-waited-and-never-implemented
new alfs tool.

The issue is that I don't know C, C++, Python, PHP and like,
thus migrating 
jhalfs to a non-bash/XSL based code will exclude me from its
development.

jhalfs born as a POC about automatizing the build from the
book sources 
instead from manually created XML profiles (like nALFS was
doing) to 
demonstrate that such thing was possible. Due the lack of
available 
programmers to implement it in compilable code, the bash
form has been 
extended and enchanced until what it is now, and what could
be in the future.

But I think the bash-based code will lack allways of a
crucial feature: the 
ability to control simultaneouslly several remote
installations/updates.

Said that, maybe you could put your hands on the development
of that new alfs 
tool based on your ideas and your own way to do the things,
helpped by other 
programmers if there is someone interested. 

I will be very happy in someday we have a alfs binary
implementation that make 
obsolete the bash-based jhalfs code.


-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.info
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

M.Canales.es wrote:
> El Viernes, 3 de Noviembre de 2006 14:39, George
Makrydakis escribió:
>> M.Canales.es wrote:
>>> The new jhalfs code may be something totally
different, thus the
>>> discussion is open to any one that would expose
thier point of view.
>> Totally different. Does this mean that the C++
route is acceptable? 
> 
> Is acceptable for the
long-time-waited-and-never-implemented new alfs tool.
> 
> The issue is that I don't know C, C++, Python, PHP and
like, thus migrating 
> jhalfs to a non-bash/XSL based code will exclude me
from its development.
> 
    As long as you have 2 free neurons able to make a
connection you can
learn. Anyone who can make sense out of xsl transforms has
the
horsepower to deal with C/C++. Being present at the birth of
new concept
makes understanding the code easier. (If you had started
browsing
jhalfs-2.0 code without having been part of its evolution
you would find 
it very difficult to understand or modify.)

> jhalfs born as a POC about automatizing the build from
the book sources 
> instead from manually created XML profiles (like nALFS
was doing) to 
> demonstrate that such thing was possible. Due the lack
of available 
> programmers to implement it in compilable code, the
bash form has been 
> extended and enchanced until what it is now, and what
could be in the future.
> 
> But I think the bash-based code will lack allways of a
crucial feature: the 
> ability to control simultaneouslly several remote
installations/updates.
> 
jhalfs-2.0 serves its purpose well, to automate the
extraction and 
building of LFS series book. It is possible to move beyond
this 
definition but not without pain.
> Said that, maybe you could put your hands on the
development of that new alfs 
> tool based on your ideas and your own way to do the
things, helpped by other 
> programmers if there is someone interested. 
> 
> I will be very happy in someday we have a alfs binary
implementation that make 
> obsolete the bash-based jhalfs code.

   jhalfs-3.0 will have another definition and code will be
written to 
support those specs. Specs first, code later.

> 
> 


-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Viernes, 3 de Noviembre de 2006 23:10, George Boudreau
escribió:

>     As long as you have 2 free neurons able to make a
connection you can
> learn. 

One and half could be enough?

> jhalfs-2.0 serves its purpose well, to automate the
extraction and
> building of LFS series book. It is possible to move
beyond this
> definition but not without pain.

Yes, and that is what need be evaluated: how many
complicated could be to move 
on the bash code to a open framework plugins-friendly in
front of porting the 
current and future planned features to a binary solution. 

>    jhalfs-3.0 will have another definition and code
will be written to
> support those specs. Specs first, code later.

I'm not good writing specs. IMHO, the new implementation
must have all 
features found in jhalfs-2.x but coded in a way that further
systems 
customizations, support for LFS-alike systems,  and features
enhancement 
could be achieved by adding plugins on top of the base code.

If that can be made using bash, call it jhalfs-3.x. If
decided that is better 
to use a compilable language based on the work and
development done from 
George M., then call it alfs-1.x,  trying to implement also
that 
not-yet-supported features found in the "alfs Software
Requirements 
Specification" specs.

I any case, jhalfs-2.x need be maintained and keeped in a
production-ready 
form until have a new tool able to replace it.

-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.info
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page