[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DotGNU]Getting the DotGNU offensive work done
|
From: |
Peter Minten |
|
Subject: |
[DotGNU]Getting the DotGNU offensive work done |
|
Date: |
Wed, 18 Dec 2002 19:01:12 +0100 |
Hi folks,
could some of you please look at the manifesto and tell me if it's finished? I'd
like to get it done before the winter meetathon.
I'd also like to encourage people to write some developer testimonials for the
This Year in DotGNU message, which by the way still needs some pieces about some
WG's and projects. I've attached a slightly modified message with a _proposed_
quote (one Gopal send in).
Greetings,
Peter
[DRAFT]
######################################################################
# #
# This Year in DotGNU 2002 #
# #
# reporting on the state of DotGNU #
# #
# #
# "made it work, now making it work better" #
# -- from The Rhys Principle #
# #
######################################################################
**********************************************************************
* *
* Foreword *
* *
* by DotGNU Working Group chairman Peter Minten *
* *
**********************************************************************
2002 has been a year of maturation for DotGNU. Old plans were replaced
with new plans, old project with new projects and in a sense old
people with new people.
The year also carried some nasty suprises. One of the biggest problems
was (and still) is lack of developers. The other big problem was lack
of code. For the architecture projects the ground work of
specification writing had to be done first before any code could be
written, luckily the specs are in the final phase and coding work is
expected to begin soon.
But despite the slowdown created by these problems there were was a
cause for celebration. The Portable.NET project reached it's most
important milestone, the compiler can now compile the baselib removing
dependency on the Microsoft C# compiler.
In the fall the organization of DotGNU was reorganized. Working Groups
were created to support cooperation between similar projects. The
leaders of all the Working Groups come together in the DotGNU Working
Group which effectively acts like a cabinet for DotGNU. Each Working
Group will explain it's goals later in this text. The role of the
Steering Committee was scaled down a bit to that of high court. The SC
still acts as the highest power in DotGNU, but it doesn't set out the
course anymore.
Last but not least the focus of DotGNU is beginning to shift from
providing as much compatibility with .NET as possible to building a
webservice supporting system which is only compatible with .NET where
absolutely needed. The DotGNU system will be a bridge which
applications can use to communicate with other applications regardless
of where those applications run, in what language they are written,
etc.
That's about what happened in the second year of DotGNU. The rest of
this message contains some background info, information about the
various active projects, explanation on the individual Working Groups,
a who is who list and developer testimonials.
----------------------------------------------------------------------
------------------------- BACKGROUND INFO ---------------------------
----------------------------------------------------------------------
**********************************************************************
* *
* Webservices - what's the mystery? *
* *
* by DotGNU Working Group chairman Peter Minten *
* *
**********************************************************************
Webservices, it's a buzzword in ICT, MS best bet, the core piece of
the next generation internet. But still who really understands what
they are?
Webservices are a hype, the expectations people have of them are
simply too high to be justified. One of the reasons for this is that
not many people can describe what they actually are, without using
marketing terms like 'The Next Big Thing'.
So it's time for some education from somebody who thinks he knows what
he's talking about. First of all let's look at the official DotGNU
definition of webservices:
<quote from DotGNU FAQ>
1.05 How do you define "webservice"?
"Webservices" are any services that are offered on the web
(regardless of what technology is used to provide them).
In order to turn this statement into an actual definition,
these explanations need to be added:
a) With "service" we mean not only that some functionality is
provided, but that there should also be some description of
this functionality, namely how the service should be used and
what it provides.
b) With saying that the service is "offered on the web" we mean
that it's offered on the internet via standard protocols,
i.e. protocols that are open, widely published, and freely
available for anyone to implement.
It is sometimes useful to distinguish between "webservice
components" which are meant to be used by other webservices, and
"webservice applications" which are meant to be used by humans
more directly. Both "webservice components" and "webservice
applications" are "webservices" as defined above.
<end quote>
Let's translate this into clear English. Webservices are things that
use the web to communicate with other things. They provide
functionality (they do something) and also tell other things what they
do and how they should be used (what input they need).
Webservices use standard protocols for communication, note that this
is not obvious, it's perfectly possible that a group of people decide
to use secret patented protocols for their 'webservices'.
I have to correct one error in the definition here: webservices don't
need to be offered on the internet, they can also be offered on (for
example) an intranet.
The definition also makes a difference between webservice components
(which are meant to be used by other applications) and webservice
applications (which are meant to be used by humans). There can be a
third form however, that communicates with both other applications and
humans. I recommend calling this form hybrid webservices. Note that I
don't talk about webservice components being used only by other
webservices because they can also be used by non-webservices.
So far for the pure definition stuff. Now what's the cool part
everybody is talking about?
The cool thing about webservices is that when you link them together
you could get a gaint complex network of computing where the most
impossible things become possible without writing code for it. Now to
pop the bubble: this is not new, this is what the inventors of UNIX
had in mind too when they created pipes and standard streams.
The only new part is that a lot of important organizations are now
trying to put up protocols to solve old problems with communication
between applications. If they are successful (have to see that first
to believe it) all webservices can understand eachother.
But that doesn't automatically mean that communication between
webservices will be easy, since every webservice will be a little
different from other webservices in the details. These little
differences will become big differences as time goes by. At the same
time people will try to preserve interoperability. Various standards
will emerge and split the world of webservices.
This may sound like a doomsday scenario, but it's already taking
place. Just look at the multi-platform bytecode systems that form the
foundation of webservice platforms. You have IL from Microsoft there,
Java from Sun and Parrotcode from the Parrot developers (note that
DotGNU will support all major bytecodes). Don't think that in the end
one bytecode will win the market, MS and Sun are software super powers
that will create a stable undecided situation between their bytecodes,
and Parrotcode is Free Software with the support of a very large
community (Parrotcode is the bytecode of Perl and in the future
probably of Python and Ruby too).
The last topic I'm going to talk about is the user interface. The
'new' part of webservices is that they run on another computer and
communicate with the user using mostly a graphical user interface
without automatically needed a browser (though webservices can use a
browser, take Phpgroupware for example). Ever heard of X? X could
create user interfaces on a workstation while running on a server
since more than a decade ago.
Now, to give a clear answer to the central question of this text
(Webservices, what's the mystery?): what mystery?
**********************************************************************
* *
* Interoperability is what we do *
* *
* by DotGNU Working Group chairman Peter Minten *
* *
**********************************************************************
DotGNU is often accused of helping Microsoft with .NET, because we
support IL and happen to work in the same area of the software
universe. This is not fair however since (besides a lot of other
things) we don't only support IL, we (theoretically) support almost
all languages.
If you don't know it yet: .NET can not support all languages, it
cannot even support most of the popular languages. The reason for this
is the Common Type System used in .NET . The CTS is a set of classes
which all CLI (Common Language Interface, the specification that
governs .NET compilers, interpreters, languages, etc) compatible
languages must understand.
The problem with CTS is that many languages don't support it. To
support CTS a language has to be redefined at the base level to
support CTS data types and classes. A change of the data types of a
language changes the language as a whole causing incompatibility with
programs written for earlier versions of the language. Imagine the
problems when you'd redefine the Ruby fixnum (which can be infinitely
big) to a 32 bits integer.
That kind of problem is exactly the reason why only MS controlled
languages are used in .NET, MS can't change the data types of Java,
besides probably getting a lot of legal troubles with Sun there would
be at least 2 compilers that each compile a different version of the
language. Those problems don't exist with Visual Basic however since
the users of that language are at MS mercy. Of course the solution to
the incompatibility problem would be to create a new language designed
for the CTS. Enter C#.
Because all languages used in .NET have to be designed for the CTS,
existing languages which are going to be .NET compatible have to be
drastically modified. Some might call this progress, I call it
assimilation of languages.
DotGNU does not use a common type system as standard. Instead of
making languages compatible at the language design level we create a
compatibility layer at the webservice level. In other words, we make
languages understand eachother regardless of how their integers look.
This makes it possible that languages cooperate without turning into
another. Where MS assimilates, we cooperate.
For example when you have a webservice written in Ruby that
communicates with a webservice written in C. The Ruby webservice sends
a request to the C webservice to do something with some very large
numbers. When the webservice system gets to command from the Ruby
webservice to send the request it first checks if the data Ruby
delivers can fit into the data type which the C webservice wants, if
not an error is generated, else the Ruby data is nicely wrapped into
the standard format used to send data over the network. At the other
side the data is converted from standard format into C format and
passed to the C webservice.
Whether you want to write a webservice in C, C++, Perl, Python, Ruby,
C#, Java or another language, DotGNU will support it.
----------------------------------------------------------------------
----------------------------- PROJECTS -------------------------------
----------------------------------------------------------------------
**********************************************************************
* *
* Portable.NET *
* *
* by somebody *
* *
**********************************************************************
[TEXT HERE]
**********************************************************************
* *
* Virtual Remote Server *
* *
* by somebody *
* *
**********************************************************************
[TEXT HERE]
**********************************************************************
* *
* Secure Execution Enviroment *
* *
* by somebody *
* *
**********************************************************************
[TEXT HERE]
**********************************************************************
* *
* address@hidden *
* *
* by Mario D. Santana *
* *
**********************************************************************
MACS is the Modular Access Control System. It acts as a sort of plexer
for different security mechanisms, allowing several independent and
incompatible authentication, authorization, and user profiling
back-ends to be used as one multi-faceted system. This scheme allows
for centralized management of decentralized user stores, to the point
that the individual user stores need not be aware of MACS. See
http://macs.sf.net/ for more.
MACS is being developed and licensed under the GPL by Mario D. Santana
and Blake Mitchell, under the auspices of Medley Software Corporation.
Medley aims to sell installation, development and support services
around MACS. In the last year, MACS has come a long way, maturing in
its design and implementation. By year's end, 0.7 should be released --
the projects first beta.
FrePort is a scheme to give users total control over their personal
information, where it's stored, and who may access it, with as little
inconvenience to the user as possible. John Le'Brecage has led the
development of this project.
The FrePort project lost much of its code in a catastrophe a while
back. Because of this, the coding phase needs to fairly begin anew.
The union of these projects is address@hidden It promises to deliver
secure, private, distributed and convenient online identity management
capability to DotGNU. And it will improve the fit of your shoes.
(Really.)
**********************************************************************
* *
* DotGNU Forum System *
* *
* by project leader Peter Minten *
* *
**********************************************************************
The DotGNU Forum System or simply Forum is a multi-user simultaneous
editing supporting system with an internal document web. That way too
complicated definition basically comes down to the following:
* Forum allows multiple users to work at a single document with
realtime updating of changes.
* Forum allows multiple users to communicate with each other while
editing.
* Forum allows documents to refer to other documents.
Working with Forum will be an experience of integrated communication
and work over large distances (if you'd build a large enough sender it
will work across the galaxy, you'd get a pretty high ping though
:-). An example:
In a normal situation you work alone on a document and send it to your
colleagues after some time. Since you are miles away from your
colleagues you'd probably use email, ftp or cvs to share the
document. To coordinate efforts you'd hold chat meetings using irc or
an Instant Messenger. At such meetings you will get pointed to
resources on the intranet of the company. You will read those
resources and make notes on them which will be discussed at the next
chat meeting.
A pretty nice system one would say, but it can be improved:
In a normal Forum situation you work on a document, at the same time
your colleagues will have the document loaded too and all changes one
of you makes appear immediately on the screens of the others. While
editing you will chat with your colleagues about what changes have to
be made. Since the meeting is done at the same time as the work time
is saved. At a certain moment a colleague points you and the others to
resources in the forum you work in (a forum is basically an
overfeatured container for documents). You all go to the resource and
while reading discuss it.
That's basically how Forum will work when it's done. But that's a
still long way to go.
----------------------------------------------------------------------
--------------------------- WORKING GROUPS ---------------------------
----------------------------------------------------------------------
**********************************************************************
* *
* DotGNU *
* *
* by DotGNU Working Group chairman Peter Minten *
* *
**********************************************************************
The DotGNU Working Group (DG WG) is perhaps the most important the
most important WG of all. It's the central counsel that steers DotGNU
in the right direction. In the past this was the task of the Steering
Committee (SC), but it was handed over to the DotGNU Working Group to
reduce the load on the SC.
The DotGNU Working Group consists of seven members, who are also the
Working Group leaders of the seven smaller working groups. These
members decide on a democratic basis about plans for DotGNU. It's up
to the developers however to go with these plans or not.
At the moment the DotGNU Working Group may seem like too much
management, but in the future when DotGNU grows larger it will be
badly needed to guard the project against fragmentation.
But even at the moment the DotGNU Working Group has a positive impact
on DotGNU by discussing plans that transcend the individual working
groups (like a plan for authorization that requires support from the
architecture people).
**********************************************************************
* *
* Foundation Code *
* *
* by somebody *
* *
**********************************************************************
[TEXT HERE]
**********************************************************************
* *
* Authorization *
* *
* by somebody *
* *
**********************************************************************
[TEXT HERE]
**********************************************************************
* *
* Architecture *
* *
* by somebody *
* *
**********************************************************************
[TEXT HERE]
**********************************************************************
* *
* Public Relations *
* *
* by somebody *
* *
**********************************************************************
[TEXT HERE]
**********************************************************************
* *
* Philosophy *
* *
* by Philosophy Working Group leader Peter Minten *
* *
**********************************************************************
The Philosophy Working Group is the guardian of Free Software
philosophy within DotGNU. It warns whenever dangerous compromises are
being made. It also mantains the DotGNU Manifesto, a document
describing what DotGNU is and why we work on it.
**********************************************************************
* *
* Webservices *
* *
* by DotGNU Working Group chairman Peter Minten *
* *
**********************************************************************
This working group is not active at the moment. In the future it will
support the webservice projects of DotGNU.
**********************************************************************
* *
* Business *
* *
* by DotGNU Working Group chairman Peter Minten *
* *
**********************************************************************
This working group is not active at the moment. In the future it will
try to set up a DotGNU cooperation to get payment to the developers of
DotGNU.
----------------------------------------------------------------------
------------------------ WHO IS WHO IN DOTGNU ------------------------
----------------------------------------------------------------------
In 2002 a lot of new developers stepped up to take responsibility in
DotGNU. Here is a list of all major developers (sorted alfabetically
on family name):
Peter Minten (silvernerd)
* DotGNU Working Group chairman
* Philosophy Working Group leader
* Forum project leader
Andrew Mitchell (ajmitch)
* Foundation Code Working Group leader
* DotGNU-Libs project leader
* Portable.NET developer
Chris Smith (Chris_S)
* Architecture Working Group leader
* VRS developer
Gopal V. (t3rmin4t0r)
* Public Relations Working Group leader
* Portable.NET lead developer and premier bughunter
* DotGNU-Libs project leader
Rhys Wheaterley (rhysw)
* Portable.NET project leader
* Steering Committee member
[OTHER NAMES HERE]
----------------------------------------------------------------------
----------------------- DEVELOPER TESTIMONIALS -----------------------
----------------------------------------------------------------------
Peter Minten
When I looked at the DotGNU website (almost exactly a year ago)
I knew this was a project to keep an eye on. These guys actually
had the courage to go into direct competition with the biggest
software firm in the world on a key area for the future.
Like David threatening Goliath with a hard little rock named
Software Freedom they looked (and still look) Microsoft in the
eye and said "We will stop you".
Let's face it, there has never been a project as ambitious as
DotGNU since the GNU project. But if we don't let ambitions turn
into greed and stay on the Right Path to Software Freedom I'm
sure we will succeed.
[TEXT HERE]
______________________________________________________________________
This Year in DotGNU 2002
All texts are Copyright (C) 2002 of their respective owners.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software Foundation.
========================== END DOCUMENT ==============================
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [DotGNU]Getting the DotGNU offensive work done,
Peter Minten <=