Trying to Bring WebM Support into Moonlight

First step: porting Matroska's JEBML (a Java parser for EBML) to C#. EBML is the "binary xml" format that is the basis for the Matroska (thus WebM) container.

I tried to convert libebml2 (written in C) to C#, but it is too "unobjectifiable" and so I searched a bit more for some easier path. Didn't look at some of the C++ parsers available, but JEBML although looking a bit abandoned of late seems to model the main concepts and surely is a good starting point. JEBML is LGPL-licensed which should not compromise the whole effort.

Going with renaming .java files to .cs, and doing wholesale Find&Replace, but have to stop now, while it doesn't even compile yet. Tomorrow I hope to fix it into a somewhat compilable state, and then, I'll need to move to .NET system classes, and use generics to slim down the whole thing.

The sources so far were uploaded into my Managed.Commons group, later I'll decide if add a project on Google Code, or GitHub.

http://groups.google.com/group/managedcommons/web/Managed.Ebml.rar

Experimenting with Twitter's Blackbird Pie, retwitting Sergio's opposition to mandatory registration to have access to Internet here in Brazil, as says a proposed set of laws:

Sou contra o cadastro obrigatório para acessar a Internet no Brasil. E você? #marcocivilless than a minute ago via webSergio Amadeu
samadeu

Some comments on new iPhone OS 4 TOS

Well, for starters, I'm one of the very  pissed MonoTouch developers, that hated all the news (mostly speculative) on the restrictions Apple is possibly bringing to iPhone development.
I'm not sure that MonoTouch will be effectively prohibited as a development platform for iPhone/iPad, but the signs are very indicative of that.
Following the discussions on blogs (and comments) and Twitter, I'm impressed by how many people is on the same boat as me, and how heated is the criticism on Apple's move.
It is contrasting to see Miguel's or Unity's calmness, so far.
Anyway this post is about one item most discussions seem to neglect or are plainly wrong about:

• Some arque that Apple can't simply prohibit some very successful apps from being further developed/distributed under the new agreement, because that would cost them money to reimburse customers that have bought those apps. That is partially false: the agreement I've been obliged to sign indeed says that Apple can, at any time, yank my app from the Apple Store and much worse they can uninstall it from all the iPhones/iPads out there which have it installed, and that any costs advent from angry customers are on my back. So they may lose on future sales if the app was very successfull, but leave all the other costs of their one-sided decision to the developers, so it is kind of an easier decision for them to make, at least in the USA.

Here in Brazil that clause is unlawful as with it Apple is abusing its stronger position to share the profits without sharing the risks, and worse transferring the costs of theirs decisions to someone else

My little library Mono.GetOptions is being abandoned by Mono

The biggest lump of code I've contributed to Mono, the Mono.GetOptions library is now being erased from the project.

It wasn't perfect and it's successor Mono.Options is a very capable replacement even if it doesn't do all the tricks Mono.GetOptions did in its prime.

Mono.Options is friendly to C# 3.0 features like lambdas, which allows writing code as terse as Mono.GetOptions allowed without using reflection and being a somewhat large dependency, the two main gripes Miguel had with my little library.

The last of Miguel gripes was about versioning (keeping more than one version in the fold) as some of the needed fixes and planned evolutions for Mono.GetOptions would mean breaking changes, which are better handled by consumers of the library by having distinct major versions with its separate APIs and attached series of minor releases.

That gets even more complex as you consider that Mono.GetOptions evolution also was tied to Mono releases.

If memory doesn't fail me, it was Mono.GetOptions and also other libraries imported into the project like SharpZipLib (which is still a problem as Mono is carrying two versions of it, and in this general cleanup process it is going over now we are trying to get rid of at least one of them), that prompted Miguel to change policy and ask for most non core libraries to be developed and released independently from Mono, even if developed by Mono hackers or used in some Mono utility. Better a package dependency (a soft one if possible) than the maintenance burden of embedded libraries.

Well let me quit reminiscing. Farewell my kid...

But if you are a loyal user of Mono.GetOptions what should you do?
You can:

1. Migrate to Mono.Options (or even use it's code directly as Miguel advocated some time ago because it is a lot slimmer than my library).
2. You can keep a copy of a Mono.GetOptions binary around to distribute with your solution (not an option for open source projects that would like to be accepted into Debian/Ubuntu).
3. Tell me you would like to see Commons.GetOptions, my own fork of it, get on the air and fly high. Version 1.0 of it has just the namespace change in it, so your migration effort would be minimal. See the Managed Commons group for more information.

Have nice developments

Document Freedom Day '10 is coming

http://documentfreedom.org/

MonoBrasil's new site is live!!!

For those Monoers able to read Brazilian Portuguese, rejoice (just kidding): our brand new MonoBrasil site is up and running.

We are still trying to fill it up with content we already had at the older site, while revising it in the process, and creating some new content, with the many, many, many new things spinning in the Mono world.

Content contributions are welcome, preferably in Portuguese (of the Brazilian variety or not), but also English/Spanish content that we may be able to translate will also be accounted as "Good Deeds" by MonoBrasil's demigods (currently that means me and my good fellow Binhara).

<pt-BR>Vejo vocês lá!!!</pt-BR>
<en>See you there</en>

We've upgraded to a Enterprise Licensed Monotouch

First thing to try (while waiting Apple bureaucracy to process our requests):

Build our prototype to the iPhone target... result: the binary of the program grows from 5MB to more than 7MB.

But I still think it is fairly sized for what it is carrying inside...