Re: [DotGNU]DotGNU policies

[Norbert Bollow]

James Michael DuPont <address@hidden> wrote:

> --- Peter Minten <address@hidden> wrote:
> > Hi folks,
> > 
> > in order to prevent future conflicts about the course of DotGNU I
> > propose the
> > following policies. I hope that if the policies are good the SC will
> > make them
> > official. If that is the case then the policies cannot be changed
> > without
> > permission from the SC (they are cast in stone until the SC pulls out
> > the rock
> > drill).
> 
> Well these are suggestions that require work to implement,
> the SC can only suggest them, but I think we need to make the plan to
> implement them.

While mdupont is right that making anything an official DotGNU
policy doesn't automatically cause the appropriate code to be
written, I do believe that the SC can make meaningful policy
decisions.  Such a policy decision would refine the answer to
the question "What is DotGNU?".  The result would be that
proposals for development projects would not get endorsed as
Official DotGNU Development Projects unless they're in line
with the policy.

> > * DotGNU shall be downward compatible with .NET
> > 
> >   Applications that run on .NET should run on DotGNU, the reverse
> > does not need to be true.

This is actually part of the DotGNU vision since the beginning, hence
no new SC decision is necessary on this point, I'll simply update the
website to clarify this point.

> That means we can expand on the bytecode ops, the class libs, the
> reflection libraries. We can provide creative and useful functions also
> as internalcalls in the pnet runtime. 

It means that the pnet project could choose to do such things, but I
believe that the pnet project has other priorities.  Furthermore, as
fasr I can see, there's absolutely nothing wrong with the priorities
that Rhys has established for the pnet project.  So I recommend that
you look for a different venue for your creativity :-)

> > * All essential DotGNU code shall be accessible from any language
> >   provided it can access functions written in C.
> > 
> >   Compatibility is our business. True compatibility does not mean
> >   assimilation (compiling everything down to one bytecode) but
> >   integration (providing ways to access stuff from one language
> >   from another).

This sounds good to me.  I was planning to fire off an email to the
mailing list of SC to ask for a vote on this until I read...

> Also it means making the bytecode interpreters accessible.

If it "also means" this, then it goes too far IMHO.  

Peter, maybe you can post a revised working of your policy proposal
which does not have this controversial implication?

Mike, if you want to make the bytecode interpreters accessible, fine.
You're welcome to hack all you want outside of the official projects,
and if it turns out that some of these creative hacks become truly
useful by helping provide end-user benefits, we can then talk about
official endorsement for such proposals.  However I'm pretty sure that
the pnet project will not accept code contributions (which increase
overall code complexity) for this purpose, and I certainly would not
want to support a policy proposal that would tell the pnet project to
accept such code contributions.

> > * All DotGNU webservices must be able to understand eachother.
> > 
> >   This boils down to using one API that works with multiple protocols
> > (XML-RPC,
> > SOAP). It also means sending serialized objects is forbidden (unless
> > webservices
> > written in any language can completely understand the objects).

I think this policy proposal is possibly a bit too strict.  I think
this should probably remain at the "proposed policy" level until the
issues are understood better.

Greetings, Norbert.

-- 
Founder & Steering Committee member of http://gnu.org/projects/dotgnu/
Free Software Business Strategy Guide   --->  http://FreeStrategy.info
Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland)
Tel +41 1 972 20 59        Fax +41 1 972 20 69       http://norbert.ch