66.66% Gone!!:

Finally my wife and son left Austin on Saturday. It was a bittersweet day for us. We really loved our time here but when everything points in one direction, it does not seem smart to fight it. I will be heading to Galicia soon.

More moving follies:

Us: We would like to ship our Jetta, small but heavy printing press, and a reduced, tiny household to Galicia, Spain. How much would that be? (We also provided the list of goods, size and weight of bigger items)

Golding shipping company: It depends on the weight, mostly. But our estimate is $8500.

Us: Hmm, what about if we leave the press?

Golding shipping company: It depends on the weight, mostly. But our estimate is $8500.

Us: Hmm, what about if we leave the press and the car?

Golding shipping company: It depends on the weight, mostly. But our estimate is $8500.

Us: Thanks!

Amber Update:

A viable solution so far for the previous post seems to be emitting dynamic modules.

The big wall is the type of the service. It requires a cast that is only known at invocation. The proxy causes an exception.

This is what I have tought so far:

*) Use reflection to prime the type ahead of time so we need to emit as little code as possible.

*) Reuse the dynamic logic with MethodRental. In short: change the cast on the fly inside the emitted module when the HostedService is reused.

To Emit Or Not To Emit:

One of the things that Microsoft's Indigo (Beta 1) allows service providers ("providers") is to expose as a service any method (even private ones)

This poses the following questions: how to reach a private method after it has been compiled?

The problem is compounded by the fact that Amber's Host ("the host") needs to use an Appdomain per type exposed as a service (which requires MarshalByRefObject) to protect providers from tripping each other.

By the time the new Appdomain is up, the object invoking the host, is not longer type "A" but MarshalByRefObject.

A direct use of reflection does not seem to be working. So far these are the following options that I have researched to solve the problem:

*) Use System.Convert.ChangeType. It may require the providers to implement complex interfaces. We may want to avoid this.

*) Use a double shot of reflection: one for dissecting MarshalByRefObject and the other to dissect the provider's type.

*) Use System.Reflection.Emit and modify the provider on the fly. Risky?

The easiest solution would be to forget reusing the instance implementing IService, the one invoking the host, this would eliminate a lot of trouble but it may be too expensive in some cases.

I will update you guys as soon as I have something working...

Amber Host:

After several interactions over email with the other Amber developers and managing to get some time off my transatlantic move chores, I am working on the host.

Some of the features are so far:

*) Per service AppDomain setup and security evidence: each type will have the opportunity of passing to Amber the setup and security evidence that has outside it.

*) Leases: it will be up to the service provider to tell the host if it wants to remain inside the host. This way hosts do not suffer from "dead" services.

*) Public/Private exception handling: as in any other piece of software a service user should expect a method to throw exceptions. The service provider may want to keep some exceptions outside the public's eyes. Public/Private exception handling will help in that regard.

*) Multithreaded services: say that user "a" is accessing service "b", method "c" and user"d" is accessing service "b", method "e". If the costs of thread bookkeeping are not excessive, the host could expose both methods in different threads (well, this is a big ?)

Red Tape Follies:

1) What do you do when official agency "A" tells you to call official agency "B" because they are to handle the issue. You call official agency "B", but official agency "B" tells you to call official agency "A"?

2) Official agency "C" gives you a form that may or may not work with official agency "D" but if it does not work please update them to make the form more usable but not official!?!?

Moving!! Amber!!

It took some time but we finally decided to cross the pond back to Galicia. Nine years in wonderful Austin are coming to an end.

After an MBA, several stints around town, trying to play corporate politics or to branch out on our own, a lot less surfing than what the doctor prescribed, and a son, you start thinking about the meaning of life and the machine that sounds PING! :-}

Of course there are more serious reasons but these are for another day.

As I mentioned in the side bar, I decided to join the Amber project as a way to give back some of what I have received from the Open Source community and as a way to take a break from our technology to regain some perspective.

Hopefullly, this will allow me to look later with fresh eyes at our code. It has a lot of work ahead but the core engine is looking good, we are just missing the coverage optimization logic :-}

As I manage to get our belongings in the container and absorb more about Amber a new comment will be added. For now this will be the common plate for all the ramblings

Some pictures from my last trip for those who were wondering which type of surfing: