Tim, others,
I like this proposal, but it is not evident to me that this is going to provide
desired returns. And I think this requires arch discussion.
Let me describe it in the meanwhile.
Description of the problems:
1- Client (asadmin) should be generic. It should not treat one command
differently from other. The major stumbling block here is that of "file
upload". Other kind of data transfer is mostly resolved.
2- Server should be able to ask client about missing option values implementing
some kind of suspend-resume semantics.
Discussion and my preference:
1) should be addressed. But I am not able to think of any frequently used data
transfer other than file, which is distinctly different from usual option name
and value kind of paradigm. So, I think server should just treat all kinds of
"files" to be locally available and accessible. Then, if a particular file is
available to the server "by path", it should just use it. If an attempt to read
such a file fails, the command fails. This has some consequences on the deploy
command's compatibility, but that needs to be addressed in some way. (The
problem with deploy command is that it is not consistent in the way it treats
its options).
So, I am suggesting a switch -- server deals with the files as if they were
available on an accessible file system. To assist that, we can consider a
command like "upload" that makes a file available to the server in its file
system.
2) is more complicated. Also it's applicable only in the cases where the
interaction is possible, which is not the case in scripted execution of asadmin.
Additionally, in the spec, I have described that in shell environment completion
is not limited to command names. It is applicable to options (that start with
"--" as well). So, it is taken care of (sort of) for shell execution.
In a scripted environment, it is generally preferred that command either
succeeds or fails, rather than waiting on user input.
So, my gut feeling is that we don't support suspend-resume or server initiated
paradigm for September release.
What do you think? (BTW, I need to decide this no later than 18th March).
Regards,
Kedar
Tim Quinn wrote:
> Jerome Dochez wrote:
>>
>> On Mar 12, 2009, at 4:01 PM, Kedar Mhaswade wrote:
>>
>>>
>>>
>>> Also, how would deploy command help when user tries
>>> something like "asadmin create-cluster" or "create-node-agent"?
>> it would not, clearly what you are proposing would be the only way to
>> solve it.
>> All I was saying is that, agreeing with Tim, it would be nice to
>> support :
>>
>> asadmin deploy myejb.jar
>> > the ejb container is not installed, do you want to install it ?
>>
>> and that's what deployment backend has some hooks and facilities for.
>> This would not be something you would be able to solve with your
>> proposal unless you would have some miracle logic. The two
>> technologies are complementary.
>>
>> I also think that solving the example above has a lot of value,
>> because a lot of users would get into such scenario, let's face it,
>> deploy and undeploy are probably to most used commands (with
>> start-domain of course).
> The discussion we started in e-mail a few days ago - where I outlined a
> general approach for allowing admin commands to "call back" to the
> client to do various things - could be used to support this for any
> admin command. Although currently the Payload implementation is used
> only for uploads of user applications during deployment and downloads of
> generated app client artifacts (coming very soon), the current
> implementation would support any kind of callback from any admin command
> - such as, oh, prompting the user with a question and accepting a response.
> For this to work, we'd need two things: the generic callback-and-reply
> framework in the server and the admin client, and the "proxy" or "stub"
> commands which don't actually execute the intended operation but rather
> advertise the existence of the full implementation and know something
> about how to retrieve and install the full implementation.
> GlassFish could come with a subclass of AdminCommand (CommandProxy?)
> which knows how to do this except perhaps for the specific question to
> ask and information about how to download and install the full
> implementation. Individual command authors could extend that
> CommandProxy, supplying the implementation for the question and the
> download logic. Done right, CommandProxy could do almost all of the
> work, making this very easy for module developers. If the full module
> were available via the Update Center, well then so much the
> better...CommandProxy could handle those details too with just some data
> differing from one CommandProxy to the next.
>
> In fact, module developers might see good value in having their proxy
> commands shipped with the standard GlassFish distribution(s) so their
> full modules would be only a mouse click or a "return" key press away
> for the user.
> - Tim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>