Hi Dave,
Thank you for pointing out where I might still have assumptions
I've not yet recognized. My comments are in-line.
On Thu, 14 May 2009, Dave Miner wrote:
> Clay Baenziger wrote:
>> Hi Dave,
>> My apologies, I think I did a poor job of communicating some
>> assumptions in my e-mails. However, I think using AI will help the intern
>> team; some of the benefits I see are:
>>
>> *To interface with the AI engine an XML manifest only needs be provided.
>> XML can easily be verified and is a well defined format which can be
>> verified by the team as they develop, allowing for an easy incremental
>> development process.
>>
>> *Building a UI is one component required for a text installer. If
>> the Slim Engine is used, then a UI and an ability to interface with the C
>> based Slim Install framework will be needed. This is two components and
>> thus more complexity and code the team would need to develop to reach the
>> same end goal.
>>
>
> I'm not sure I buy your comparison. I look at it as:
>
> - the existing GUI interfaces to the slim engine using C, so examples of
> doing that are available
I agree that there are examples, but I see the maintainability of C code
to be inferior to that written in Python as any new functionality will
need to be coded up from scratch and error handling in C must be done at a
far lower level than using the OO try/except methods in Python, for
example.
Further, Python has what appears to be a mature curses library
interface[1] which should allow them to take full advantage of Python
error handling and rapid object-oriented coding practices without much
effort.
1: http://www.amk.ca/python/howto/curses/
> - there is no existing code written to emit AI manifests. That'll have to be
> developed from scratch.
Though there is no code to emit AI manifests, there are example AI
manifests which could be modified and there are XML engines in our source
base which can easily be used to output XML.
For example, LXML[1] has an Element Tree API which is geared explicitly to
creating an XML document. (It's how the AI webserver generates XHTML.)
Further, the output for the team then can be validated against the AI
schema which is a very easy target to test against.
1: http://codespeak.net/lxml/api.html
> I suspect you have an unstated assumption about how the team might implement
> a text UI which perhaps is coloring your evaluation?
I think I mainly see the team as being well versed in C++ and Java but not
C, so feel Python to be a more natural fit for us to learn from their OO
skills and experience, rather than fitting them into a C world and us into
more C code which could be written in a higher level language.
Admittedly I hold a strong insecurity about using C versus a more modern
language which I suspect is a strong bias away from C solutions.
> Beyond that, there's no useful progress reporting from the AI engine, while
> there is well-defined functionality for that built into slim. I'd view
> useful progress reporting as an essential feature of a UI.
I agree! This is an drawback which I had not pondered long on. Though
there is work to be undertaken here for AI -- we know it needs better
progress reporting -- until that API is defined this is a problem.
However, the team could define an API for receiving such information. Thus,
when implemented, it will seamlessly integrate. This work could aid us in
implementing better progress reporting from AI too.
>> *Using the AI engine allows maximal functionality in the future, however,
>> if the Slim Engine is used that limits future functionality as that
>> engine was never developed to be a configurable and extensible
>> installer - it serves our "one button install" use case - only.
>>
>> *A "one button install" straightforward and simple use case can be built
>> through an AI manifest without exposing all of the features of AI, if we
>> don't want to.
>>
>
> Both of which are true, but their value depends on establishing the desired
> functionality.
Yes, of course, I see a wide open future as good -- but it's not always
actually of use and sometimes causes problems with clarity. Still,
however, I see any functionality we'd like to add above a one button type
install as requiring modification to the slim install bits opposed to
simply rearranging XML.
Thank you for your insights on why the slim engine is a potential choice,
as I had not see compelling arguments that way and I now feel I could at
least defend the choice. I still don't feel it's as useful as using AI,
however.
Thank you,
Clay
> Dave
>
