Dear All,
I have uploaded an add-on package to http://www.squeaksource.com/MagmaTester called 'Magma server requests'. This is as mentioned in a previous email to this list but it is now packaged in a generic form independent of Gjallar.
to install with Installer use:
Installer mc http: 'http://www.squeaksource.com'; project: 'MagmaTester'; install: 'Magma server requests'.
After installing the package into a working Magma installation, you will need to do a MagmaSession cleanUp to get it adopted by the MagmaRepositoryController's
I have made it fairly generic since it passes arbitrary messages, and returns any values, trapping server-side errors, it transports them back over the wire in order to signal them in the client.
Actions are atomic since, and I quote from the "Magma client server" read-me text. "The answer block is only ever evaluated for one client request at a time."
So to use this all you have to do is implement the Client side and the server side in MyOwnServerRequestResponder
e.g. Client side:
MyClass-counterValue
^ (self magmaSession serverRequest counterValue) submit
e.g Server side
MagmaRequestResponder subclass: MyOwnRequestResponder -- MyOwnRequestResponder-#counterValue
^ Count := Count + 1 -- RequestResponder-class-#requestsSupported
^ #( #counterValue ) --
You can send a batch of requests like so...
(self magmaSession serverRequest counterIncrement; counterIncrement; counterIncrement; counterValue) submit
-- Then there is a handy server backdoor!
Normally each request in a batch of requests is sent to the responder which can handle each request. However if we enable requests to be chained, such that the next request is sent to the result of the previous request we can gain full remote control of the server. This is enabled by MagmaServerBackdoorResponder which in itself only serves one request: #login:password:
e.g.
((self magmaSession serverRequest login: 'admin' password: 'magma rocks') repositoryController isReadOnly) submit
To do:
The login could be tied in to magma's exisitng users management. Some responders need simple persistence for their use which I do not know how to do
enjoy
Keith
I have made it fairly generic since it passes arbitrary messages, and returns any values, trapping server-side errors, it transports them back over the wire in order to signal them in the client.
"Ma client server" does not support a dynamic protocol; only fixed which must be established just before session negotiation. How do you handle this?
On 6/15/07, Keith Hodges keith_hodges@yahoo.co.uk wrote:
Dear All,
I have uploaded an add-on package to http://www.squeaksource.com/MagmaTester called 'Magma server requests'. This is as mentioned in a previous email to this list but it is now packaged in a generic form independent of Gjallar.
to install with Installer use:
Installer mc http: 'http://www.squeaksource.com'; project: 'MagmaTester'; install: 'Magma server requests'.
After installing the package into a working Magma installation, you will need to do a MagmaSession cleanUp to get it adopted by the MagmaRepositoryController's
I have made it fairly generic since it passes arbitrary messages, and returns any values, trapping server-side errors, it transports them back over the wire in order to signal them in the client.
Actions are atomic since, and I quote from the "Magma client server" read-me text. "The answer block is only ever evaluated for one client request at a time."
So to use this all you have to do is implement the Client side and the server side in MyOwnServerRequestResponder
e.g. Client side:
MyClass-counterValue
^ (self magmaSession serverRequest counterValue) submit
e.g Server side
MagmaRequestResponder subclass: MyOwnRequestResponder
MyOwnRequestResponder-#counterValue
^ Count := Count + 1
-- RequestResponder-class-#requestsSupported
^ #( #counterValue )
You can send a batch of requests like so...
(self magmaSession serverRequest counterIncrement; counterIncrement; counterIncrement; counterValue) submit
-- Then there is a handy server backdoor!
Normally each request in a batch of requests is sent to the responder which can handle each request. However if we enable requests to be chained, such that the next request is sent to the result of the previous request we can gain full remote control of the server. This is enabled by MagmaServerBackdoorResponder which in itself only serves one request: #login:password:
e.g.
((self magmaSession serverRequest login: 'admin' password: 'magma rocks') repositoryController isReadOnly) submit
To do:
The login could be tied in to magma's exisitng users management. Some responders need simple persistence for their use which I do not know how to do
enjoy
Keith
Setools mailing list Setools@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/setools
magma@lists.squeakfoundation.org