|
From: |
Unknown |
For example this would make it is easy for the secret police of
any Evil Government to create complete logs of all
Passport/Hailstorm based transactions done by people in that
country.
Greetings, Norbert.
--
Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland)
Your own domain with all your Mailman lists: $15/month http://cisto.com
Business Coaching for Internet Entrepreneurs ---> http://thinkcoach.com
Tel +41 1 972 20 59 Fax +41 1 972 20 69 address@hidden
From what I understand, the solution to this problem involves
zero-knowledge algorithms. Basically, I prove to you that I know the
solution to a problem without ever revealing to you the actual solution.
To be honest, I have yet to spend much time working on implementing this,
so I'm still kind of fuzzy on how it works. So far, I've just used
Diffie-Hellman for key exchange using clear-text password authentication.
I haven't gotten to the point where anyone was really interested in seeing
the authentication improved since usage is amongst a small group of
friends, but I've done a lot of reading in anticipation of the day that it
might become necessary. I'm working with some PhD students at Harvard and
MIT on a next generation authentication architecture, where I might try to
write some type of zero-knowledge scheme, since I haven't yet found a
package available for Java.
The protocols I've encountered so far to do zero-knowledge authenticaiton
are SNAPI, SRP, SPEKE, OKE, AuthA, AMP, and PAK.
Here are a couple of links:
http://www.integritysciences.com/links.html
http://www.bell-labs.com/user/philmac/pak.html
I also have the papers on SNAPI and PAK in postscript, which I can send
you if you're interested.
David
On Fri, 6 Jul 2001, David Sugar wrote:
> I would like to hear more about this also. However, I also tend to agree
> that
> simpler systems tend to work best unless there are demonstratable flaws in
> them.
>
> Norbert Bollow wrote:
>
> > David,
> > this sounds very interesting, but please clarify... what is
> > the advantage of such a system over a simple approach like this:
> >
> > "I hand you a RSA public key, and next time I come around, you
> > send me a random message encrypted with this public key. I'll
> > prove that it's me by decrypting the message."
> >
> > ?
> >
> > Greetings, Norbert
> >
> >
> >> From: "David J. Thomson" <address@hidden>
> >> Date: Fri, 6 Jul 2001 14:04:47 -0400 (EDT)
> >>
> >>>> i could hand you an applet, and say "use this applet
> >>>> to verify who i am next time i come around"
> >>>>
> >>>
> >> I'm working on such an authentication scheme. It turns out that this is
> >> not a trivial problem to solve. It's been solved mathematically, but
> >> there aren't too many real-world applications. I'm working on implementing
> >> this in a way that would prevent someone else from forging your "applet".
> >> Mail me directly if you would like to talk about this further so that we
> >> don't clog the main list.
> >>
> >> David
> >
> > _______________________________________________
> > Developers mailing list
> > address@hidden
> > http://dotgnu.org/mailman/listinfo/developers
>
>
From my perspective the main reason for doing PR work at this
early stage is to attract developers who will help us with
implementing this huge project.
> Either way we should have more quotes from more people.
Yes. Especially we should really have a quote or two from
Myrddian. He deserves some recognition for starting this
project (provided he wants it :).
> We should get a lot more feedback, too, though. This does take considerable
> work to get it right.
Yes. There is no point in doing this in a hurry.
We should definately show it to the FSF before release. Also,
why not show it to Ximian and give them the opportunity to
comment. I'm thinking of this as an act of courtesy - they
might appreciate this even though we don't mention Mono.
> [the contact line goes at the end. You can include me and David as the US
> contacts, Tony Stanco, address@hidden, David Sugar,
> address@hidden Radi and Arun as the Indian contacts,
> address@hidden, address@hidden, you are the Swiss contact
> and Myddrian as the Austrialian contact.
Should there be telephone numbers for the contacts?
> Some people call the GNU/Linux system "Linux", but this misnomer leads
> to confusion (people cannot tell whether you mean the whole system or
> the kernel, one part), and spreads an inaccurate picture of how, when
> and where the system was developed. Making a consistent distinction
> between GNU/Linux, the whole operating system, and Linux, the kernel, is
> the best way to clear up the confusion.
>
> [how much of this is needed if the audience is developers?]
I think it will be appreciated by the FSF when we include this
note in the release. The editors will not use this part unless
they feel that it is of interest to their readers. But at least
it will give the editor some understanding why we talk about
"GNU/Linux" and not simply "Linux".
Greetings, Norbert.
--
Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland)
Your own domain with all your Mailman lists: $15/month http://cisto.com
Business Coaching for Internet Entrepreneurs ---> http://thinkcoach.com
Tel +41 1 972 20 59 Fax +41 1 972 20 69 address@hidden
From
Hewitt's writings of the time, he clearly saw the security implications of
the formalism, and may have been the first to realize that it could be a
basis for transparent secure distributed computing without a shared TCB.
Unfortunately, Hewitt is not a great communicator, and, being in the MIT AI
culture, he eventually stopped caring about security.
Scheme, which was inspired by Actors, seemed to only pick up about half of
what was valuable about Actors -- full lexical closures, first class
continuations, control flow as message passing, minimalism. Most modern
languages considered good have learned from Scheme, but have not bothered
to
learn from Scheme's ancestor. The half Scheme forgot includes capability
security, transparent distribution, event-loop concurrency, everything is
an
object (pervasive message dispatch). However, by sticking faithfully to
the
spirit of the lambda calculus, Scheme miraculously remained almost secure
during the decades when no one cared about this.
Rees' paper is a glorious rediscovery of the capability security latent in
Scheme, and in similarly almost pure lambda languages. This time the
connection is superbly well explained. Between this explanation and
several
capability secure lambda languages (W7, Joule, E), perhaps, this time, the
connection won't get lost. Now if we can only get the OS folks to think
first in these terms, rather than the broken Lampson ones.
>They are. In Scheme, a variable is always bound to a location. a
>location is always mutable and contains a value.
>
>At least two people on the e-lang list, Rees being one of them, have
>asserted that this is a design flaw of Scheme (I can point you at the
>messages if you like--it was like 6 months ago), and I agree.
>[...]
>ML lets you do that with minimal fuss. in particular, ML's variables are
>by default bound to (immutable) values; to get mutability, you bind the
>variable not to an ordinary value like an (immutable) integer but rather
>to what called a ref (although "loc" would have been a more apt term,
>IMO). refs and mutable arrays are probably the only mutable data types
>in ML.
For comparison, as a result of the discussion on the e-lang list referred
to
above, a variable in E is by default immutable. A mutable variable is seen
as being, under the covers, an unnamed immutable variable designating a
Slot
object. http://www.erights.org/javadoc/org/erights/e/elib/slot/Slot.html
A
Slot is a first class reification of Scheme's notion of location, and
therefore, I take it, to something like ML's "ref"s.
>[...] Specifically, noting that ML is a statically typed language,
>instead of declaring
>
> i : integer
In E:
def i :integer := #..initial value expression
As you mention below, E is a dynamically typed language. If I understand
modern language design terminology correctly, E is a variety of dynamic
typing called "soft typing". The "integer" in the above expression is a
"ValueGuard" expression
http://www.erights.org/javadoc/org/erights/e/elib/slot/ValueGuard.html .
The definition is evaluated by evaluating the ValueGuard expression
("integer") to a ValueGuard, evaluating the initial value expression to an
initial value, and asking the ValueGuard to coerce the initial value. If
this succeeds, "i" is bound to the result. A soft type dynamically fails
to
type check when a ValueGuard fails to coerce.
>one would declare
>
> ri : ref integer ("ri is of type ref containing an integer")
In E:
var i :integer := #..initial value expression
Now the expression after the colon is a SlotGuard expression. It is
evaluated to produce a SlotGuard
http://www.erights.org/javadoc/org/erights/e/elib/slot/SlotGuard.html .
The
definition's evaluation proceeds much like before, but the SlotGuard's
"makeSlot" method is invoked rather than a "coerce" method. The resulting
first-class Slot object is then used to hold the value of the variable
"i".
Type-like objects, such as that bound to "integer" in the initial scope,
are
expected to respond to both SlotGuard and ValueGuard protocol, enabling
them
to be used in both contexts.
There is nothing fundamental about the "var" declaration. One could
transform it away as follows:
var i :vge := ive => def ri := vge makeSlot(ive, null)
i := newValue => ri setValue(newValue)
... i ... => ... (ri getValue()) ...
... &i ... => ri
An E program in which all "var"s have been transformed away is in "final
normal form" (FNF).
>and then one would write !ri (pronounced "deref ri" I suggest) to fetch
>from the ref and ri:=53 to store into the ref. i:=53 is a type error.
>so is
>
> ri * 3
>
>--one has to write
>
> !ri * 3
In normal E, "i * 3" is fine. The FNF form of this expression would be
"ri getValue() * 3"
>The folks on the e-lang list seem to prefer dynamically typed languages.
Speaking just for myself, I chose to make E dynamically types. Although
I'm
committed to that path for the next many years of my life, I frankly don't
know which I prefer. It's one of the hardest tradeoffs a language designer
faces.
>There is no reason why a dynamically typed language could not use its
>type system to distinguish between mutable and immutable data the way
>FPLs do, but I do not know of one with a currently maintained
>implementation.
If I understand you correctly, E qualifies for the reasons explained above,
and I am maintaining its implementation. Perhaps not well, but with the
recent Combex announcement (briefly, we got money), things should improve
rapidly.
> certainly no language used by more than 100 programmers
>at any give time.
Ok, not yet. Watch this space.
>And I know nothing about Smalltalk
It does not. All variables are mutable.
>Prolog might do it but Prolog is unsuitable for cap programming
>for other reasons.
Curiously, Concurrent Prolog and most of its progeny (such as ToonTalk) are
fine capability systems. The invention of Concurrent Prolog probably
represents the third independent invention of capability computation,
though
this time in a horn-clause inference context. However, because Udi Shapiro
is an honorable scholar, you wouldn't know it from his papers. He became
aware of Actors before the first paper ("A Subset of Concurrent Prolog and
its Interpreter") was done, realized that Hewitt had already stated the
important properties many years earlier. So he cites it as prior work. I
know a bit more of the history only by conversations with Udi.
Cheers,
--MarkM
_______________________________________________
cap-talk mailing list
address@hidden
http://www.eros-os.org/mailman/listinfo/cap-talk
From now on, notification of updates of the DotGNU website will
now longer be posted here on the developers list, but I will
post the notifications to the website mailing list. When an
update is relevant to one of the technical mailing lists
(currently arch and auth) I will CC: that notification to that
technical mailing list. The purpose of this "notification"
procedure are:
a) Use "release early and often" feedback cycles to quickly
improve the website,
b) Make sure that the website will truthfully represent the
vision for DotGNU and not merely my opinions.
You can subscribe to the new "website" mailing list at
http://dotgnu.org/mailman/listinfo/website
Greetings, Norbert.
--
Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland)
Your own domain with all your Mailman lists: $15/month http://cisto.com
Business Coaching for Internet Entrepreneurs ---> http://thinkcoach.com
Tel +41 1 972 20 59 Fax +41 1 972 20 69 address@hidden
From day one, the Mono project was not an "anti-Microsoft"
project, like our is. Mono was from the beginning, and still
is, a business project of Ximian.
That said, I feel that it's possible that there may be a win-win
deal between Microsoft and Ximian which does not stop us from
also cooperating with Ximian in some way.
The biggest question is whether Ximian will remain faithful to the
plan of using GNU GPL for Mono. Microsoft will certainly try to
bully them into making concessions in that area.
I'm also concerned about possible legal implications of talking
with Ximian folks and/or looking at their code if they get
"insider information" from Microsoft. Tony is working on
putting together a legal team which can look into this
matter.
Greetings, Norbert.
--
Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland)
Your own domain with all your Mailman lists: $15/month http://cisto.com
Business Coaching for Internet Entrepreneurs ---> http://thinkcoach.com
Tel +41 1 972 20 59 Fax +41 1 972 20 69 address@hidden
From what I understand, the '#' operator is used to reference
something with the `source'. (And not used to perform an
operation on the `source'.)
For example, what if I wrote:
http://www.whereever.dom/a/b/c/guess.php#gunzip
Would it try to gunzip it? Would it display it, and try
to jump to the place marked `gunzip'?
You might be thinking, we can figure this out based on
the mine type... but let's give a better example. What
if I had:
http://www.whereever.dom/a/b/c/guess.php#gzip
Then what? (Do I want to gzip it, or jump to the
place maked `gzip'?)
My question is, since DotGNU seems to be using URIs
for alot of things, is there a general method for
handling `sources', `sinks', and `functions' in the
spec. [I am asking for anyone on the list that knows
alot about URIs to answer here.] (The above
mentioned hacks will not be acceptable.)
If there isn't maybe we should develop one.
I suggested on the Nautilus list, that maybe something
like:
[gzip|tar]http://www.somewhere.dom/here/
should be used. But that's just one possibility. And
I don't know if that will conflict with any of the
specs on what a URI should be.
(BTW, that above URI says, get the `source'
"http://www.somewhere.dom/here/";, then tar it, then
gzip it.)
Also, that sytle of new URI (above) has limitations.
(For example, you can't represent a DAG with it.)
Just though it was important to bring up, since URIs
seem to be important to DotGNU.
See ya
Charles Iliya Krempeaux
From a business perspective, 'a' and 'b' are essentially two
attempts to gain dominance in an emerging market that currently
largely held by Free Software (such as GNU/Linux, Apache, Perl,
PHP, MySQL) and software from Sun Microsystems (Solaris and
Sun's Java implementation).
'a' and 'b' are both scary. If Microsoft succeeds with 'a',
that could be the end of the internet being easily accessible
with Free Software. If Microsoft succeeds with 'b', that is
perhaps even more scary, because who would believe that
Microsoft is capable of preventing a skilled "blackhat" from
gaining access to the data. Also, if all transactions go via
Microsoft's "Passport" system, that makes it very easy to every
secret service in the word to monitor who does what.
DotGNU is all about preventing Microsoft from reaching these
goals by
a) Creating a platform for distributed computing that is far
more powerful than what Microsoft is envisioning for .NET
b) Creating a fully decentralized authentication / virtual
identities system that can favorably compete with Microsoft's
Passport system.
Now I can answer your question... in order to be more powerful
than Microsoft's .NET, the DotGNU platform must be able to do
everything that Microsoft's platforms can do (and more).
"Portable Excutables" that were created for Microsoft's .NET
must work on the DotGNU platform.
These "Portable Excutables" use a bytecode format called
"Intermediate Language" (IL). Microsoft has submitted
specifications for this bytecode format to a standards
organisation (ECMA).
For details you can refer to
http://www.dotnetexperts.com/ecma/index.html
This part of DotGNU that is responsible for achieving "downward
compatibility to .NET" is now (since the merger of DotGNU and
Portable.NET) called the "DotGNU Portable.NET" project of
DotGNU. For more infromation you may refer to
http://www.southern-storm.com.au/portable_net.html
Greetings, Norbert.
--
A member of FreeDevelopers and the DotGNU Core Team http://dotgnu.org
Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland)
Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://thinkcoach.com
Your own domain with all your Mailman lists: $15/month http://cisto.com
From the moment I picked your book up until I laid it down I was convulsed
with laughter. Some day I intend reading it. -- Groucho Marx
From this release onwards, a new version numbering scheme will be used.
Versions that end in an odd number refer to the working CVS version
(e.g. 0.1.3). Versions that end in an even number refer to a released
version (e.g. 0.1.4). Released versions will have a CVS tag. For
version 0.1.4, this tag is "r_0_1_4".
Cheers,
Rhys.
From what I can tell, the laws of the secure execution environment are
set up to keep worm-like activity from happening. (An applet may only
communicate with the machine it was downloaded from, etc...)
Also, a comment in that article about which languages are used to write
viruses is very misinformed. The whole point of .NET is that the
language doesn't matter. Once the code is sent to a machine and
downloaded, everything is in IL.
I am not na=EFve enough to think that there will never be a worm or =
virus
written in .NET, but you folks have to take the blinders off and realize
that these steps are going in the right direction. .NET is light-years
ahead of ActiveX or anything else MS has produced in the past as far as
security is concerned.
From the article:
"What are web services?
Web services are a group of closely related, emerging
technologies that describe a service-oriented,
component-based application architecture that is based
on an open, Internet-centric infrastructure. Web
services represent a model in which discrete tasks
within e-business processes are distributed widely
throughout a value net. Web services components can be
recombined by other companies to meet the needs of
their own software applications or business
processes."
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
From LinuxUser. More DotGNU mentions.
http://www.linuxuser.co.uk/articles/issue15/lu15-Cover_feature-Tempted_by_net.pdf
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
From Computerworld, reporting on an announcment at COMDEX:
Nokia, rivals form software powerhouse to develop 3G services
A group of mobile phone makers and network operators led by Nokia
is forming a consortium to develop open-source software for a
global operating system that could directly challenge Microsoft
and its .Net strategy.
http://computerworld.com/nlt/1%2C3590%2CNAV47_STO65677_NLTAM%2C00.html
-- Rich
From what I've heard it's Jabber Inc which has so far prevented
a GPL-compatible release of JOSS, and they consider it to be in
their best commercial interest if GNU creates a GPL'd Jabber
server.
They don't want to help us, but they expect us to help them in
return?
> I and most of the Jabber fans would welcome a GPL/GNU Jabber server that
> competes head to head with the JOSS and JCS.
I agree that creating such a beast would solve the problem...
but this is not a strategic priority for GNU. Our focus is on
replacing proprietary software, not on replacing open source
software which happens to have GPL-incompatible licensing.
Microsoft is making a move called .NET which aims to gain an
effective monopoly of the internet. We're fighting back, and we
want to wrestle the effective desktop monopoly away from
Microsoft. In this kind of war, we don't want to get
side-tracked by replacing an open-source IM server which (from
our perspective) has no serious problems besides its
GPL-incompatible license.
I understand that the matter looks different from the
perspective of a Jabber fan, that you think that it's worth the
effort to create a GPL'd Jabber server.
I'd welcome a DotGNU project to create a set of webservice
components for the DotGNU platform which each can speak XML-RPC
as well as one or more of the Jabber protocols, and which
together form a GPL'd Jabber server. However, from the
perspective of DotGNU (and GNU as a whole) this project would
not be of strategic importance... the driving effort behind it
would have to come from the Jabber fans, no-one else is likely
to invest much sweat into it.
Greetings, Norbert.
--
A member of FreeDevelopers and the DotGNU Steering Committee: dotgnu.org
Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland)
Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://thinkcoach.com
Your own domain with all your Mailman lists: $15/month http://cisto.com
From a brief look at that website I get the impression that this
is not what we're looking for... we don't want to replace "the
web" with "a decentralized, distributed network with
confidential and authenticated communication".
> Has any thought been given to this storage component yet,
> other than it needs to be decentralized?
There have been some discussions (on the arch list?) a while
back, but they didn't get very far. Probably the details won't
get worked out until someone wants to start implementing it.
Greetings, Norbert.
--
A member of FreeDevelopers and the DotGNU Steering Committee: dotgnu.org
Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland)
Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://thinkcoach.com
Your own domain with all your Mailman lists: $15/month http://cisto.com
From the beginning we have been concerned that probably
Microsoft's intention with .NET is to ensnare and trap
developers. There can be no doubt that this unscrupulous
proprietary software company wants to extend their effective
desktop OS monopoly to Authentication / Authorization / Virtual
Identity systems on the internet. One of the main objectives
of the DotGNU project is to prevent that from happening, and in
general provide tools for webservices without "vendor lock-in" of
any kind. So the "Webservices Ethics" department would like to
draw your attention to these articles:
3. Email discussion of policies for authentication and IDsec
between Richard Stallman, David Sugar and Tony Stanco
[DotGNU is sponsored by FreeDevelopers (founded by Tony
Stanco) and by the GNU project (founded and led by Richard
Stallman). David Sugar is the chairman of the DotGNU Steering
Committee.]
4. Questions and Answers about "Webservices"
by Norbert Bollow (Steering Committee member and co-founder
of the DotGNU project)
Section C: DotGNU -- The Big Picture
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5. Origins of the DotGNU project
by Barry Fitzgerald (Steering Committee member and co-founder
of the DotGNU project)
6. An overview of DotGNU
by DotGNU Steering Committee chairman David Sugar
7. A formula for DotGNU
by DotGNU Steering Committee member Arun M.
Section D: DotGNU -- A Community
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This section contains notes from various contributors to the
DotGNU, project in which they explain why they care about DotGNU.
#################################################################
# #
# Section A: DotGNU -- Making the Web Work for You! #
# #
# Article 1: DotGNU Portable.NET (with its C# compiler, #
# runtime and related development tools) #
# #
# by Portable.NET lead developer Rhys Weatherley #
# #
#################################################################
The Portable.NET project was begun in January 2001, with the goal
of building a runtime engine, a C# compiler, and the C# system
library.
Early on, I realized that much of the infrastructure needed for a
runtime engine was identical to the code needed for a C#
compiler. In particular, the metadata reading and writing
routines in the runtime engine could also be used as the internal
class representation for the compiler.
>From this early core, the assembler, disassembler, and the other
development tools quickly emerged. At this point, the runtime
engine, the compiler, and the C# library were still in an
embryonic form. The C# library was split out of the "pnet" tree
into "pnetlib" specifically so it could be reused by other
projects.
Around late April, it became clear that the C# compiler was
becoming a problem to maintain. The level of complexity was so
great that bugs kept creeping into the code. I had used similar
designs on previous compiler projects, and had also had problems
with complexity. My design was technically correct, but the
sheer number of details kept sinking the code. So I went back to
the drawing board to rethink the design and to do some research.
The result was the "treecc" tool, which provides an
aspect-oriented approach to building compilers. The complexity
that used to cause so many problems was now trivial to handle.
The C# compiler was re-written in early July and was a marked
improvement. I also discovered that it was very easy to use the
treecc framework to support languages other than C#, and bytecode
formats other than IL. Support for compiling C# to the JVM and
for compiling Java to IL should be coming in early-2002.
Portable.NET and DotGNU merged in August. A lot of progress was
made on the core infrastructure, the pnetlib C# library, and the
C# compiler. But the runtime engine was still lagging behind.
The polymorphic nature of the instruction set was making it very
difficult to build an efficient engine.
I began work on another background research project to devise a
new engine. This culminated in the "Converted Virtual Machine"
(CVM) in October 2001, a radically new design for bytecode
interpreters. Instead of interpreting the difficult IL
instructions directly, the bytecode is converted into another
instruction set that can be interpreted efficiently.
One of the major benefits of the new engine design is that it
will be very easy to add support for JIT's in the future. CVM
itself is essentially a "bytecode JIT". Most of the hard work is
already done, which should make writing a native JIT a fairly
simple task.
At the end of 2001, Portable.NET had reached the stage of being
able to run simple example programs, and even a few complex ones
such as the "Curse of Frogger" video game.
The biggest area to be dealt with in early 2002 is completing the
C# compiler and the C# library, and then beginning work on an x86
JIT.
From my own personal perspective, I find Portable.NET interesting
because of the research into language implementation techniques
that has arisen from my work on the project. I'm hoping to be
able to "spin off" other tools like treecc that are not only
useful to Portable.NET, but are also useful to other Free
Software projects.
#################################################################
# #
# Section A: DotGNU -- Making the Web Work for You! #
# #
# Article 2: phpGroupWare (a collection of groupware #
# applications which can be used from any browser #
# and also from other programs via XML-RPC). #
# #
# by phpGroupWare lead developer Dan Kuykendall #
# #
#################################################################
phpGroupWare is a web-based and web service for groupware
applications. It includes all the standard PIM applications such
as email, calendar, address-book, todo list, and notes. But due to
the powerful, well defined and easy to use API we developed other
applications can and have been fully integrated. All applications
are optionally installed so that the admin can pick and choose
only the applications that meet the needs of their users.
Normally users take advantage of the terrific web interface from
any browser on any platform they choose, because we stick to pure
HTML standards as much as possible. The web interface is the most
fully supported interface to the applications in phpGroupWare
but not the only one. With the use of the simple XML-RPC protocol
which we now support in phpGroupWare, developers and users can
access the applications functionality and data from other
applications. These applications would need to be written in a
language that supports XML-RPC but that includes most that I am
aware of. This makes phpGroupWare a "web service" because it is
offering up is functionality as a service to other applications
and this gives developers and users alike great power and
flexibility.
Web services are not the answer to all problems, but they open up
great possibilities for platform and language independence as
well as making it easy to offer greater shared code and
functionality than ever before. The possibilities are only
becoming visible, but they *will* change how applications are
developed from this point on.
With the combining of forces with DotGNU we will be able to
leverage our collective knowledge and experience to develop
outstanding applications and services for users. DotGNU is
focused, among other things, on authentication services and
platform independent bytecode solutions while the phpGroupWare
team focuses on Groupware based solutions. When the two come
together phpGroupWare will use the Authentication services of
DotGNU and DotGNU will have some real world working groupware web
services making use of their technology. Even more importantly
the phpGroupWare team is able to lend experience on things such
as a universal preferences settings service which will follow the
authentication services effort. phpGroupWare will immediately
make use of the DotGNU standards as they come out and are
appropriate giving DotGNU a great testing ground and giving
phpGroupWare the opportunity to influence what are sure to be
important standards.
#################################################################
# #
# Sec. B: DotGNU - Keeping You from Getting Tangled in a Net! #
# #
# Article 3: Email discussion of policies for authentication #
# and IDsec between Richard Stallman, David Sugar #
# and Tony Stanco #
# #
# [DotGNU is sponsored by FreeDevelopers (founded #
# by Tony Stanco) and by the GNU project (founded #
# and led by Richard Stallman). David Sugar is #
# the chairman of the DotGNU Steering Committee.] #
# #
#################################################################
David Sugar wrote:
~~~~~~~~~~~~~~~~~~
Identity services allow people to roam from one content
provider's web site to another without having to refill forms or
provide information separately, such as credit card information,
etc.
Richard Stallman wrote:
~~~~~~~~~~~~~~~~~~~~~~~
Does this enable all those web sites to work together to collect
information about you? That is one of the things people regard
as a threat to privacy. Think of doubleclick, for instance.
David Sugar wrote:
~~~~~~~~~~~~~~~~~~
If done incorrectly it does. The key question is how to protect
privacy and provide convenience for people that do not otherwise
understand what they are surrendering thru convenience. In the
IDsec method, at least right at the start no single central
authority has every users data; rather any number of profile
providers can be providing it, including your own workstation,
and on a selective and controlled basis.
However, this doesn't in itself prevent the possibility of
collecting user data in the way you speak of, as it happens
already today. If one goes to site A and B, and happens to
permit sharing of, say, a credit card number with both, certainly
sites A and B can form a common database keyed on the common
credit card and identify people that way. Other kinds of data
can also be common keyed to try and match users between sites.
What IDsec does provide for, and in fact what we want in DotGNU,
is that no single entity will have a master database of every
user and hence one cannot form a single master common keyed
database of everyone that can be sold to other commercial
entities directly. Since separate and unique session keys are
used, unless common and unique identifying data (like say a
credit card # or ssn) is being permitted to be shared, there is
no direct way to determine that user "X" visiting site "A" is
also user "Y" visiting site "B". In IDsec there is direct user
control of what data is shared and with whom, and used correctly,
one can prevent correlative data from being shared if one uses it
purely for session identity so when I visit site "A" I simply
tell it I am the same "X" I was last time and share no data at
all and have the simple convenience of no login and single global
sign-on. Used this way it does not tell anyone that "A" presented
to site "X" is also "B" on site "Y". One can also keep multiple
profiles, including anonymous ones, and choose which identity to
use when visiting a given site. Of course, it does not prevent
or protect users who do share correlative data, but neither does
manual entry in today's world except thru the occasional typo :).
IDsec is certainly not perfect, and may require some thought to
use in a way that does protect privacy fully, but it is a far
better solution than those otherwise being pushed for today.
There are things we may wish to change in IDsec to make it better
for privacy, but it is at least seems a reasonable starting
point.
Tony Stanco wrote:
~~~~~~~~~~~~~~~~~~
Yes. IDsec seems to be on the right track. The question is not
should all that information be accumulated, but by whom. I should
have all the information about me on my machine. Others should
only have parts. And I think IDsec allows this. In fact, for
those who know some accounting, the system should be like double
entry accounting. I have all my information because I deal with
everyone, but they only have the other side of the transaction
that I did with them.
This is important, because I have all my information, but more
importantly, I can CHECK everyone else's information about me. If
I don't have the information on my machine, I have no way of
knowing what others have on me, or be able to correct errors that
they may have made.
David Sugar wrote:
~~~~~~~~~~~~~~~~~~
IDsec certainly does allow this, where you can have complete
information on yourself on your machine, and others have
incomplete but factually correct information as you permitted to
share and which you control the update and correction of. It's
original intent, however, was clearly to enable the creation of
internet identity providers as third parties; that the individual
can be such a third party is almost a side-effect of their
original design :).
As I said, IDsec is certainly not perfect, but it is close to or
can be made to do what we envisioned. As free software we will
be able to influence it's better aspects. One such way would be
to make it fairly easy and painless for any user to setup their
own identity service. That being said, I am not opposed in
principle to the existence of third parties that wish to
aggregate users and offer identity services so long as anyone can
commercially offer such services, companies can provide it to
shield their employee information from such third parties if they
choose, and there is the ultimate choice of being my own identity
service.
That it can enable commercial providers of identity services will
provide incentives for commercial interests to adopt it over
solutions that they would have no control over. That a bank or
financial institution can securely provide identity to their
existing customer base rather than put it in the hands of a third
party is a compelling selling point for them. In this respect, I
see IDsec as potentially interesting because it can successfully
align many commercial interests with our own ethical ones.
Tony Stanco wrote:
~~~~~~~~~~~~~~~~~~
Yes. Agreed.
I think that most people will opt for a commercial provider,
which they should be free to do. And yes, banks are a natural
candidate. They are already really just data centers; it just
happens to be financial data. But this is also why they are
deathly afraid of losing control. MS called them dinosaurs a few
years back (which really is right), and they are now afraid of
any loss of control of their data and guard it with their
life. (One reason e-banking is moving so slowly). But they will
eventually have to join a system and it might as well be ours.
I still suggest that we provide local backup capacities on the
personal machines, even if people opt for commercial providers,
otherwise they will be subject to lock-in. So while a commercial
provider may be a live repository, everyone should have a backup
on their own machine to protect/check their data and so they can
change providers easily.
#################################################################
# #
# Sec. B: DotGNU - Keeping You from Getting Tangled in a Net! #
# #
# Article 4: Questions and Answers about "Webservices" #
# #
# by Norbert Bollow #
# (a co-founder of the DotGNU project together #
# with Enzo-Adrian Reyes and Barry Fitzgerald) #
# #
#################################################################
What are webservices good for?
When a program is implemented as a "webservice", its
functionality can be used by other programs which can be
implemented in any programming language, and which can run on
any computer which is connected to the internet. This makes it
possible for example that multiple users in different parts of
the world can interact with a single set of data.
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.
What about other definitions of "webservice"?
A definition attempt by the Stencil Group has been discussed in some
detail on the DotGNU developers mailing list, in these messages:
* http://archive.dotgnu.org/pipermail/developers/2001-November/001252.html
* http://archive.dotgnu.org/pipermail/developers/2001-November/001253.html
* http://archive.dotgnu.org/pipermail/developers/2001-November/001254.html
* http://archive.dotgnu.org/pipermail/developers/2001-November/001255.html
Are webservices "the future", or will something better be invented soon?
Who knows? Right now it looks like webservices may become the
preferred way for implementing all kinds of intranet- and
internet-based computer applications, for the following
reasons:
* Loose coupling between components: Each component can be
implemented in the preferred programming language of the
implementors of that component, regardless of what languages
and development tools have been used to implement other
components. There is less organizational overhead to develop
changes or enhancements to various components in parallel.
* Rapid prototyping and an easy transition from prototype to
production: Prototypes of webservice components can be
conveniently implemented in scripting languages like Perl,
Python or PHP. The transition to production will typically
include moving the component to a different server (or
several load-balanced servers) and possibly also a more
efficient re-implementation of the component.
Is the data stored on the webservice server?
Data can be stored either locally or on the webservice server.
If multiple users need to interact with the same set of data,
then it should probably be stored on the webservice server.
This raises the legitimate concern of whether a webservice
provide can "lock in" customers by making it inconvenient or
impossible for them to get at their data; this issue is
addressed in the following questions.
Can we move to a different webservice provider?
The DotGNU webservice server requires that for each webservice
and each set of data that it acts on, there is an "owner of the
data" who has the right to download the entire set of data
together with the program which implements the webservice.
Program which have been downloaded in this way can be executed
in any DotGNU Secure Execution Environment on a desktop
computer or on a DotGNU webservices server.
(This means that when there is a need for an application to use
data from multiple sources, where no-one has ownership rights
to all the data, then the application must be divided into
multiple webservice components.)
Can we get source code for the webservice programs?
If all of the following conditions are met, then the webservice
provider is required to distribute the source code for the
webservice program to you, upon your request:
* The webservice program has been licensed to the webservice
provider under the terms of the GNU General Public License,
or it is a derivative work of such a program.
* The webservice program runs on a DotGNU webservice server.
* You are recognized as an "owner of the data" for this
webservice.
Then the webservice server will upon your request distribute
the program to you in binary form. According the terms of the
GNU General Public License, this implies that the webservice
provider must upon request distribute the source code for the
webservice program to you.
Am I obligated to give away my webservice source code?
You are not automatically obligated to distribute your source
code, and you are certainly not obligated to just give it away.
However, if you sell webservice services, then your customers
will expect that you make them the "owner of the data" which
the webservice uses, and depending on the exact circumstances
that may indirectly give these customers a right to get the
source code upon request. Here are the details:
If you provide a webservice using a GPL'd webservice program
(which you may have modified), then the "owner of the data"
will be able to obtain the webservices programs under the terms
of the GNU GPL, and this implies in particular that they will
have a right to get the source code of the exact version of the
program which you're using. The terms of the GNU GPL also
require you to make a written promise to this "owner of the
data" that you will be willing to provide the source code upon
request. This ensures that the "owner of the data" will know
about this right to the source code.
The "owner of the data" is typically a paying customer, and the
fact that the customer has a right to get the source code
increases the value of the service you provide. Therefore you
will be able to charge a higher price and/or close more sales.
You can use the DotGNU development tools to program your own
webservices (instead of just modifying the webservice programs
which are distributed with DotGNU, or which others have made
available under the GNU GPL) and then your are not required to
make source code for these webservices available to the
customer who is the "owner of the data". However, even in
these situations where you are not required to make the source
code available to your customers, we strongly encourage you to
provide the source code to your customers under the terms of
the GNU GPL anyway. We believe that this is ethically the
right thing to do, and that it will be good for your business.
#################################################################
# #
# Section C: DotGNU -- The Big Picture #
# #
# Article 5: Origins of the DotGNU project #
# #
# by Barry Fitzgerald #
# (a co-founder of the DotGNU project together #
# with Enzo-Adrian Reyes and Norbert Bollow) #
# #
#################################################################
The introduction of the DotGNU project on the FreeDevelopers
mailing list back in June of 2001 brought many arguments. People
wondered what value it would bring to the GNU/Linux world and
shuddered at the thought of dealing with Microsoft founded
technologies. Many people even wondered if the project would
inadvertently help Microsoft. In the time since the idea first
came up, the discussions refined the idea until a founding
philosophy was designed. Our goals were not simply compatibility
with the Microsoft platform, we decided almost right away that
there was an obligation to create a webservices framework that
would ensure that the freedom of the members of our community
would be protected. If our work helped out the proprietary
companies of the world to subjugate the members of our community,
then the project would have been for nothing. So, it became the
mandate of the leaders of the project to ensure that protection
of freedom was a key aspect of this project.
"Webservices" is the new buzzword. Every tech writer is talking
about webservices when they talk about the future of the tech
world. The question is, where do these new webservices fit into
the larger picture? If you're to believe some people,
webservices are the future and the standard method of running
programs is defunct. If you're to believe others, webservices
are a fad and no one will ever use them. As with most tech
prognostication, both will most likely be partly true. The fact
of the matter is that the success of network services (webmail,
etc...) is already happening and these services are
complimenting the computer usage of people every day. This has
been the case been for some time as well. To allow this market
to be overtaken by a proprietary vendor would be unthinkable.
So, we must embrace the world the way it is and create a Free
framework with which webservices and larger network service
enabled applications can be easily constructed, allowing for
competition in the marketplace, security, freedom, and privacy.
#################################################################
# #
# Section C: DotGNU -- The Big Picture #
# #
# Article 7: A technical overview of DotGNU #
# #
# by David Sugar #
# (chairman of the DotGNU Steering Committee) #
# #
#################################################################
DotGNU is in part concerned with producing bytecode runtime
systems for portable executables, and of course, we are
interested in the ECMA "standardized" bytecode system and
creating a freely licensed and fully portable implementation as
represented by the Portable.NET project. Having a portable and
universally interoperable runtime for developing and delivering
web hosted applications represents an important part of DotGNU,
as does extending support to other existing bytecode systems such
as Java.
Another part of DotGNU is concerned with providing a fully valid
and technically correct solution for authentication and user
identities that provide the convenience of internet-wide single
sign-on services without the need to deliberately handicap such
systems thru a single vendor point of failure or implement such a
solution in a manner that forces users to compromise personal
data or which compromises the integrity of commercial
organizations. Certainly there is neither any technical merit
nor commercial reason to have one and only one source of
authentication and identity services on the Internet.
While enabling the existence and use of multiple trusted third
party identity services is quite valid and useful commercially
when such services can be hosted on a non-discriminatory basis by
any organization wishing to do so in a free and open market,
rather than by either a single vendor or a small group of
privileged vendors, ideally we wish it to be possible for an
individual user to provide identity and personal data services
directly from corporate offices or even their own workstation if
so desired to protect their personal data to the fullest.
Tying together authentication, identity, and runtime, are
meaningful services, and DotGNU also will produce useful web
hosted application services that will demonstrate the full cycle
of authenticated single login in a secure manner with personal
data that can be kept private and secure or hosted by trusted
third parties and using the Portable.NET runtime to deliver these
services where they involve local execution on your workstation,
all using freely licensed software under the GPL and hosted on
freely licensed operating systems, such as GNU/Linux.
#################################################################
# #
# Section C: DotGNU -- The Big Picture #
# #
# Article 7: A formula for DotGNU #
# #
# by DotGNU Steering Committee member Arun M. #
# #
#################################################################
DotGNU = Runtimes/Compilers
+ AppServer
+ WebServicesDevelopmentFrameWork
+ CommonServices
+ DesktopIntegration
Runtime
C# runtime (Pnet) is major component of DotGNU,
But DotGNU will support others like parrot, Kaffe etc.
Various language compilers for CIL are needed.
AppServer
An application server based on CIL/C# is needed. It will take
more time as we need to complete C# corelibs.
Now the question is, should we restrict AppServer to C#? Can
we add other existing AppServers to DotGNU ? A few choices
are Zope, Webware, eZPublish, phpCMS. Will they be
interested in joining ?
WebServicesDevelopmentFrameWork
A set of libraries for common web service standards is a
major component in this. Most AppSevers now have xml-rpc or
SOAP support. Some even support WSDL.
I feel SandStorm may be a good addition to DotGNU in this
regard.
CommonServices
Identity is the first component. IDSec, macs etc comes here.
Groupware comes next (solved by phpGroupWare). Another major
one is ERP system available as webservice. GNUe should join
DotGNU, or DotGNU should work on a webservice plugin for GNUe.
DesktopIntegration
Desktop applications will have to be written to support the
services we provide.
#################################################################
# #
# Section D: DotGNU -- A Community #
# #
# DotGNU is not just a collection of software, but also a #
# Community of Free Software developers. Here are some #
# notes from various contributors to the DotGNU project, in #
# which they explain why they care about DotGNU. #
# #
# (The submissions are sorted according to their length) #
# #
#################################################################
Bill Lance writes:
~~~~~~~~~~~~~~~~~~
The Internet came to life at the rim when it dropped the idea of
a central server. The forces of government and finance wish to
pull power back to the center and regain control. The pressure
to things like ASP's, subscription/teathered software, and server
centric webservices are manifestations of this today and reveal
their strategy. DotGNU seems to me to be the incubator of the
LibreSoftware alternative. That's why I'm here.
Bradley Kuhn writes:
~~~~~~~~~~~~~~~~~~~~
DotGNU is of particular interest to me and I was honored to be
put on the Steering Committee this year. DotGNU has the
potential to bring together years of work in programming language
integration research, and marry it beautifully with web services.
I have in the past worked on using the Java Virtual Machine as a
language integration platform, thus I am excited that DotGNU's
Portable.NET might make true language integration possible.
- Bradley M. Kuhn, Vice President of the FSF and DotGNU SC Member
Norbert Bollow writes:
~~~~~~~~~~~~~~~~~~~~~~
If everyone uses webservices, and these programs use Microsoft's
centralized auth system, then secret services and other crackers
can easily observe how anyone is using their PC. This could far
too easily become the foundation of a "Big Brother" type
totalitarian system. Microsoft is a Goliath. From the beginning
of DotGNU I have felt somewhat like a David challenging this
Goliath, doing what needs to be done, in the name of Jesus. Yes,
I believe that for DotGNU to be successful, we need to have God
on our side.
Barry Fitzgerald writes:
~~~~~~~~~~~~~~~~~~~~~~~~
DotGNU has the potential of solving a number of problems that
currently keep developers in the habit of creating programs for
That Other Platform. We could create a unified, cross-system
compatible and completely interoperable development environment
for multiple language development. This would be a boon for the
entire development industry and would solve many potential
program availability issues that currently keep GNU/Linux from
becoming ubiquitous in the market. This aspect provides a unique
opportunity to place Free Software at the forefront of the
industry if we take our steps wisely. Interoperability truly is
king, but we must do more than interoperate. We must create the
best Dam*ed development environment that ever existed. In the
long run, this is our mandate. We must, along with the rest of
the Free Software world, do what it takes to dethrone the
proprietary forces of the world.
Dan Kuykendall writes:
~~~~~~~~~~~~~~~~~~~~~~
I have been working with phpGroupWare since its inception as the
project leader. I have had several years of experience as a
groupware administrator of all three of the big commercial
groupware servers and felt that all of them lacked in some way or
another. When phpGroupWare started I knew that I could help build
a groupware server that did not have all the failings of the
commercial products in both features and lack of freedom. By
helping build both the code and the community I feel that my
efforts have been a tremendous success. phpGroupWare is a
powerful, flexible and *free* product that can meet and exceed
the needs of many many people. When I became aware of web
services and realized their potential I immediately started to
push phpGroupWare in that direction because I knew that web
services would change the rules, and I wanted to be there. Our
code has so easily been adapted and continues to be a perfect
testing ground for new technology that I know we have built
something to be proud of, and I believe the DotGNU team has show
great vision and wisdom in including us into their team. I
believe phpGroupWare and DotGNU can be successful and offer the
world top rate applications and services without giving up
freedom or features.
David Sugar writes:
~~~~~~~~~~~~~~~~~~~
There were many things that concerned me when I first heard about
DotGNU. Of course, like many others at the time, I was highly
skeptical of such an enterprise until I took the time to think
deeper on the subject. There are those that say that DotGNU
helps legitimize ".NET" services from Microsoft. I believe Java
already does this very well. The problem Java faces is that Sun
does not wish to relinquish control to certain parts of it, just
as Microsoft chooses not to relinquish control to parts of it's
so called ".NET" technologies, especially in regards to
authentication and web services.
Neither situation is valid or useful for web centric free
software to progress. To create software on a non-free
infrastructure (Java) is problematic even if the resulting
software itself can be freely licensed. Worst still would be to
create a free infrastructure or runtime that integrates with
proprietary services and protocols, as the latter, while free on
the surface, can be used to lock out any other vendor solutions
at the key middleware services level and in fact could be used to
effectively block free software development by changing licensing
on key services and protocols that may later be required. While
it's easy to pretend that these things will not happen or will
never be adopted by others, the fact remains that burying one's
head in the sand will not make the problem go away.
DotGNU is about assuring freedom, for both developers and users.
In this sense, I, among others, understood it was necessary to
look at and engage in the full spectrum of services, from basic
runtime to web services and protocols, and to do so in a manner
that protects the integrity of user's private data. This was why
I chose to become part of DotGNU, because I thought it was far
better to do something than simply ignore the problem and hope it
would simply go away...
===================================================================
"This year in DotGNU - No 1" -- All articles are Copyright 2001 by
their authors. Compilation Copyright 2002 by Norbert Bollow. All
rights reserved. Verbatim copying and distribution of this entire
issue is permitted in any medium or format, provided this notice is
preserved.
===================================================================
From my limited understanding of the current dotGNU technology, it's probably
the Phoenix engine that'll be of most interest, if anything.
Whatever you think, I'd be glad to add my experience to development effort
if needs be.
Regards,
Chris
--
Chris Smith
Technical Architect - netFluid Technology Limited.
"Internet Technologies, Distributed Systems and Tuxedo Consultancy"
E: address@hidden W: http://www.nfluid.co.uk
From IBM.
http://www.alphaworks.ibm.com/tech/webservicestoolkit
__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
From their site:
"The Globus Project is developing fundamental
technologies needed to build computational grids.
Grids are persistent environments that enable software
applications to integrate instruments, displays,
computational and information resources that are
managed by diverse organizations in widespread
locations."
Globus is the LibreSoftware front defining open
protocols and API's for the Grid.
It would seem to be wisely foreward looking if we be
aware of this thing, maintain compatability with their
design, and even look to their protocals and API
design in the dotgnu development where appropriate.
I'm sure MS will come out with something in this
territory when the time is right, and it will
certainly be designed to control and tax how its used.
It would be most interesting if Libresoftware could
already be ahead of them in that game.
__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
From the point of view of the interfaces, as long as the
original method in "TextWriter" is not changed to "abstract",
this should be OK. The current "csdocvalil" validation
process checks for things that are missing or different.
Not for things that are extra.
But, we would normally need a very good reason to do
something like this. e.g. the spec is wrong. Efficiency
shouldn't be our primary concern just yet, especially
if it steps outside the spec.
In the case of "StringWriter", there is little point in
overrdding any more than "(char)", "(char[], int, int)",
and "(string)" - all three of these are listed in the spec.
Most of the others have to convert to "string" first,
regardless of whether you do it in the parent class
or the override. So there is no efficiency gain.
Cheers,
Rhys.
From the JAVA side of things:
http://xml.com/pub/r/1315
__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com
From http://www.fsf.org/licenses/license-list.html:
Common Public License Version 0.5
This is a free software license but it is incompatible with
the GPL.
The Common Public License is incompatible with the GPL
because it has various specific requirements that are not in
the GPL.
For example, it requires certain patent licenses be given
that the GPL does not require. (We don't think those patent
license requirements are inherently a bad idea, but
nonetheless they are incompatible with the GNU GPL.)
From the article:
Sun's Platform for Network Identity comes in two versions.
The $150,000 Enterprise Edition is for internal computer networks
and includes two Sun Fire 280R servers, a 72GB StorEdge D2
storage system, the iPlanet directory server software and 10
days of consulting from Sun's Professional Services group.
It can manage up to 10,000 online identities at a cost of
about $15 per user.
Huh? $150,000 seems a little steep for basically an SQL
database storing profile information and a HTTP front-end.
MS are no doubt laughing their heads off about this one.
Maybe I just don't get it, but authentication has always
seemed to me to be "yet another daemon" to run on an
existing server farm, with near-zero admin costs over
and above the existing farm costs.
Cheers,
Rhys.
From the metadata section, I see!
>but it wouldn't be difficult to write
> a C program which flattens them into a browser
> database
> to be linked with the executable.
That is great! what function/module loads these
structure into memory? The
>
> Another possibility is to use CIL itself for the
> metadata,
> with native functions for the method bodies. i.e.
> create
> an extracted version of the metadata section,
> which is dynamically loaded by pnet's metadata
> library when the application starts up.
Yes that is the idea.
>This metadata is embedded
> into the application as a const data blob.
Yes and if needed could be loaded as a separate dll on
demand, if we are dealing with a C# frontend it might
not be needed by all programs. Think about a hello
world.
That is how the gcc handles builtins, a normal
function type header pointing to some optimised
function bodies.
What do you think as a first step :
Creation of a set of transformation of native c
functions given a simple c function_type to a CIL
metadata block and the generations of the CIL code to
link to it? The later code that can transform c# into
c would be able to use that tranformation to get back
at its meta data.
Of course we are dealing with OO verses C, but it is a
first step.
That would allow for any lib to be linked into a CIL
and provide the metadata that is needed to invoke it.
(Getting us back into the abuse of the GPL discussion)
The inclusion of the pnet api that you mentioned for
programs to access and load this CIL meta section
would allow for any program to load its meta-data.
Then we need a api to call c# functions from inside c,
because you want to get at the meta data, resolve the
functions an invoke dynamically.
The generated c for such a reflection call would hard
to be optimisied.
We will have to classify the types of the reflection
usage into
NONE (dont need, dont care, dont want)
TRIVIAL(iterate over and execute block), get classname
etc)
HARD (recursive iterations over meta structure)
IMPOSSIBLE (like creation of new classes on the fly,
or the evaling of code)
The solution is IMHO compile time reflection and
meta-programming like done in openc++, where you
install hooks into the compiler and execute user
specific code to get at the meta data and transform
your code. Some of the reflection code could be
optimised out like that. A form of template expansion.
Think about "iterate over all my fields and create a
print statement for them".
A c# frontend to the gcc would emit calls to this
reflection lib when usage of the reflection classes
demands linkage.
Best Regards,
Mike
=====
James Michael DuPont
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/
From an M$ EULA.
" Recipient may not reverse engineer, decompile or
disassemble the Product except to the extent that
this restriction is expressly prohibited by
applicable
law. "
So Illegal !. Extracting signatures would endup as disassembling
when an M$ lawyer argues. (especially when "viral software" is involved !)
> We could try to start creating a description of the link level interface of
> all the methods and functions on the level of the user of MFC.
....
> Of course it would be lots of work to implement, but if that is what we have
> to do.......
Actually it's none of our bloody headache now. We've got our
hands full with C# alone. After dealing with C# we can think about
these things.
> Does this sound like too much work or a flawed idea?
Do my comments answer that question (or what !).
Gopal.V
--
The difference between insanity and genius is only measured by success
//===<=>===\\
|| GNU RULEZ ||
\\===<=>===//
From the IRC discussion last night, there appears to
be some sticky issues with the InternalCall methods
that are needed by System.Net.Socket that I didn't
fully appreciate until now.
Part of the problem stems from Microsoft putting the
Socket class in the wrong place. It should be in the
"runtime" assembly, not in the "System" assembly.
But it's too late to change that now.
The other problem stems from the need for classes in
"System" to access many of the platform layer things in
"Platform". e.g. "Platform.Errno". But "Platform" lives
in "runtime", and is declared "internal".
Solving this problem without introducing security or
maintainence problems is a difficult task. Making the
"Platform" classes in "runtime" public creates security
issues, but putting extra copies in "System" is a
maintaince problem waiting to happen. Catch-22.
Here's a suggestion:
We put the "SocketMethods" class into "runtime" and
call it "Platform.SocketMethods", so that all platform
internals are in the same place. This will require that
some of the "Platform" classes be declared "public"
so that "System" can access them.
To prevent anyone else from accessing them, we will
mark the classes with a special attribute that says
"public only to System". When the runtime engine
sees this attribute, it will refuse to allow anything
except "System" to access the methods.
Right now, I can't see any other way around this without
putting a huge amount of object knowledge in the engine,
or copying the Platform classes into "System", which I
want to avoid. It's a bit of a hack, but a smaller hack
than anything else I've been able to come up with.
I'm open to other suggestions.
Cheers,
Rhys.
From the reflection api you can get alot of that
information.
>If I
> wasn't already busy , I would have demonstrated
> instead of talking.
Point taken, Well I do talk alot. Right now I am
cleaning up a bit of my sources, then I will be able
to contribute a bit more and talk less. :=)
I will not post anything more untill I have done some
more homework. I promise!
mike
=====
James Michael DuPont
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
From the FSF:
"Common Public License Version 0.5
This is a free software license but it is incompatible with the GPL.
The Common Public License is incompatible with the GPL because it has
various specific requirements that are not in the GPL.
For example, it requires certain patent licenses be given that the GPL
does not require. (We don't think those patent license requirements are
inherently a bad idea, but nonetheless they are incompatible with the GNU
GPL.)"
Daniel.
Date: Wed, 10 Apr 2002 07:04:15 +1000
From: Rhys Weatherley <address@hidden>
To: address@hidden
Subject: Re: [DotGNU]Common Public License
Bill Lance wrote:
> What do the License specialist here have to say about
> the Common Public License:
>
> http://www.eclipse.org/legal/cpl-v05.html
I'm pretty sure we've covered this one before. According
to the FSF, the GPL is a Free Software license that is
incompatible with the GPL:
http://www.fsf.org/licenses/license-list.html
Cheers,
Rhys.
From my Point of view, DotGNU should use Windows.Forms (Mono's or
another implementation), thus having GUI interfaces and capable of
running at least most of the Windows apps.
regards and thanks for any comments,
Timo
From what I can see from the Parrot docs, it is a common set
of useful opcodes and behaviours, to which language-specific
rules may be added.
What would be interesting is for someone to investigate writing
a Parrot library in C# that can translate Parrot bytecode into
IL on the fly, and which has hooks to allow languages like Perl
and Python to plug in their own behaviours. I'd do this myself,
as it would be really cool, but I'm kinda busy. :-)
Cheers,
Rhys.
From Dave Farber's Interesting People list,
address@hidden
Seth Johnson
-------- Original Message --------
Subject: IP: : Comment on NPRM 02-33
Date: Thu, 2 May 2002 15:32:22 -0500
From: "David Farber" <address@hidden>
-----Original Message-----
From: "David S. Isenberg" <address@hidden>
Date: Thu, 02 May 2002 16:13:48
To: address@hidden
Subject: Comment on NPRM 02-33
Dave,
This is the comment opposing FCC Notice of Proposed
Rulemaking (NPRM) 02-33 that I told you I'd write. NPRM
02-33 threatens to turn back the network architecture clock
to pre-Internet days. Please distribute it via IP as soon
as you can -- the deadline for comments is tomorrow, and
I'd like as many IPers as possible to comment.
IPers -- You can read the original NPRM at
http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-02-42A1.doc
FCC comments should follow the form below. Email them to
the FCC's Electronic Comment Filing System: address@hidden
ECFS - E-mail Filing
<PROCEEDING> 02-33
<DATE> 5/2/02
<NAME> David S. Isenberg
<ADDRESS1> 112 Orchard Street
<ADDRESS2>
<CITY> Cos Cob
<STATE> CT
<ZIP> 06807
<LAW-FIRM> none
<ATTORNEY> none
<DOCUMENT-TYPE>CO
<PHONE-NUMBER> 203-661-4798
<DESCRIPTION> Email Comment
<CONTACT-EMAIL>address@hidden
<TEXT>
I am writing to oppose the reasoning behind NPRM 02-33,
"Appropriate Framework for Broadband Access to the Internet
over Wireline Facilities", because I am afraid that treating
broadband Internet access as an information service (as
proposed by NPRM 02-33) would deprive United States citizens
of the single most important feature of the Internet that
has made it such a runaway success over the last decade.
Let me introduce myself. I have a Ph.D. in Biology from the
California Institute of Technology, where I studied human
speech. I spent 12 years, 1985-1998, at AT&T Bell Labs,
where I served as Distinguished Member of Technical Staff.
Today, I make my living as an independent commentator on
telecommunications. While I serve on numerous advisory
boards and have numerous clients, I am beholden to no
commercial interests. I am writing as a concerned citizen
of the United States, and I am writing with hope that recent
great advances in communications technology -- and, more
importantly, in network architecture -- will become
available to all.
In my understanding, "access" involves connecting my
computer (and other digital communications devices) to the
Internet. "Information" is quite different -- information
is in the ones and zeros that enter my computer to be
processed by it. Information can flow into my devices over
a variety of "access" -- over a wire, over a cable, over an
optical fiber, or through the air (either as radio-frequency
energy, or as light-wave energy). That is, the same
sequence of ones and zeros can enter my computer by any of
these access methods. So to equate "access" with
"information", as does NPRM 02-33, is simply incorrect.
It was not always so. The telephone network was developed
to deliver one kind of information -- the human voice. It
was engineered for voice, and it gave access to voice.
Everything else that it carried (e.g., touch tones, modem
signals, signalling information to set up telephone calls)
was either an exception, or an adjunct to voice telephony.
The wire that came into the house could not be distinguished
from the service it provided. It was the same for
television and radio -- each had its own dedicated
infrastructure (be it a wire or a frequency band) to carry a
specific type of information.
The great advance of the Internet was that its fundamental
architecture separated "access" from "information". Any one
of the various forms of access to the Internet puts one in
touch with an infinite array of information. Furthermore,
providers of this information (information service
providers) do not own special infrastructure -- all they
need is a server and any of the several methods of Internet
access. As a result, the Internet is wide-open to
innovation, and we have applications and services like
email, Web browsing (in all its manifestations), ecommerce,
Internet telephony, streaming audio and video, chat and
instant messaging.
Not a single one of these information (and communications)
services was brought to market by a telephone company or a
television company or a cable operator or a broadcast radio
network. No, access is a fundamentally different business
from "information service". To equate "broadband access"
and "information service" -- as NPRM 02-33 proposes -- would
be a horrendous step backwards.
Without separation, "broadband access" as an "information
service" is likely to resemble the failed Interactive TV
experiments of the early 1990s. TV-on-speed is not "the
Internet" -- and vice versa.
David I
-------
************ WE HAVE MOVED! ***************
New Snail-Mail Address, effective March 1, 2002:
isen.com
112 Orchard Street
Cos Cob CT 06807
New phone: 203-661-4798
*--------------------isen.com----------------------*
David S. Isenberg address@hidden
isen.com, inc. 888-isen-com (inside US)
http://isen.com/ 203-661-4798 (direct line)
*--------------------isen.com----------------------*
-- The brains behind The Stupid Network --
*--------------------isen.com----------------------*
For archives see:
http://www.interesting-people.org/archives/interesting-people/
From Dave Farber's Interesting People list,
address@hidden
Seth Johnson
-------- Original Message --------
Subject: IP: : Comment on NPRM 02-33
Date: Thu, 2 May 2002 15:32:22 -0500
From: "David Farber" <address@hidden>
-----Original Message-----
From: "David S. Isenberg" <address@hidden>
Date: Thu, 02 May 2002 16:13:48
To: address@hidden
Subject: Comment on NPRM 02-33
Dave,
This is the comment opposing FCC Notice of Proposed
Rulemaking (NPRM) 02-33 that I told you I'd write. NPRM
02-33 threatens to turn back the network architecture clock
to pre-Internet days. Please distribute it via IP as soon
as you can -- the deadline for comments is tomorrow, and
I'd like as many IPers as possible to comment.
IPers -- You can read the original NPRM at
http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-02-42A1.doc
FCC comments should follow the form below. Email them to
the FCC's Electronic Comment Filing System: address@hidden
ECFS - E-mail Filing
<PROCEEDING> 02-33
<DATE> 5/2/02
<NAME> David S. Isenberg
<ADDRESS1> 112 Orchard Street
<ADDRESS2>
<CITY> Cos Cob
<STATE> CT
<ZIP> 06807
<LAW-FIRM> none
<ATTORNEY> none
<DOCUMENT-TYPE>CO
<PHONE-NUMBER> 203-661-4798
<DESCRIPTION> Email Comment
<CONTACT-EMAIL>address@hidden
<TEXT>
I am writing to oppose the reasoning behind NPRM 02-33,
"Appropriate Framework for Broadband Access to the Internet
over Wireline Facilities", because I am afraid that treating
broadband Internet access as an information service (as
proposed by NPRM 02-33) would deprive United States citizens
of the single most important feature of the Internet that
has made it such a runaway success over the last decade.
Let me introduce myself. I have a Ph.D. in Biology from the
California Institute of Technology, where I studied human
speech. I spent 12 years, 1985-1998, at AT&T Bell Labs,
where I served as Distinguished Member of Technical Staff.
Today, I make my living as an independent commentator on
telecommunications. While I serve on numerous advisory
boards and have numerous clients, I am beholden to no
commercial interests. I am writing as a concerned citizen
of the United States, and I am writing with hope that recent
great advances in communications technology -- and, more
importantly, in network architecture -- will become
available to all.
In my understanding, "access" involves connecting my
computer (and other digital communications devices) to the
Internet. "Information" is quite different -- information
is in the ones and zeros that enter my computer to be
processed by it. Information can flow into my devices over
a variety of "access" -- over a wire, over a cable, over an
optical fiber, or through the air (either as radio-frequency
energy, or as light-wave energy). That is, the same
sequence of ones and zeros can enter my computer by any of
these access methods. So to equate "access" with
"information", as does NPRM 02-33, is simply incorrect.
It was not always so. The telephone network was developed
to deliver one kind of information -- the human voice. It
was engineered for voice, and it gave access to voice.
Everything else that it carried (e.g., touch tones, modem
signals, signalling information to set up telephone calls)
was either an exception, or an adjunct to voice telephony.
The wire that came into the house could not be distinguished
from the service it provided. It was the same for
television and radio -- each had its own dedicated
infrastructure (be it a wire or a frequency band) to carry a
specific type of information.
The great advance of the Internet was that its fundamental
architecture separated "access" from "information". Any one
of the various forms of access to the Internet puts one in
touch with an infinite array of information. Furthermore,
providers of this information (information service
providers) do not own special infrastructure -- all they
need is a server and any of the several methods of Internet
access. As a result, the Internet is wide-open to
innovation, and we have applications and services like
email, Web browsing (in all its manifestations), ecommerce,
Internet telephony, streaming audio and video, chat and
instant messaging.
Not a single one of these information (and communications)
services was brought to market by a telephone company or a
television company or a cable operator or a broadcast radio
network. No, access is a fundamentally different business
from "information service". To equate "broadband access"
and "information service" -- as NPRM 02-33 proposes -- would
be a horrendous step backwards.
Without separation, "broadband access" as an "information
service" is likely to resemble the failed Interactive TV
experiments of the early 1990s. TV-on-speed is not "the
Internet" -- and vice versa.
David I
-------
************ WE HAVE MOVED! ***************
New Snail-Mail Address, effective March 1, 2002:
isen.com
112 Orchard Street
Cos Cob CT 06807
New phone: 203-661-4798
*--------------------isen.com----------------------*
David S. Isenberg address@hidden
isen.com, inc. 888-isen-com (inside US)
http://isen.com/ 203-661-4798 (direct line)
*--------------------isen.com----------------------*
-- The brains behind The Stupid Network --
*--------------------isen.com----------------------*
For archives see:
http://www.interesting-people.org/archives/interesting-people/
--
See <http://www.cs.umbc.edu/agentslist> for list info & archives.
From what I understand, their beta is over (or so their website says)...
but it appears that some of the fallout has source and is posted on
sourceforge...
The premise was the have a distributed P2P universe where all resources
were assigned a pseudo-dyndns style internal name -- and each client had
a mini-webserver in it (or some such facility). You could publish
information or files on your peer and then someone else could search for
that piece of data using the mojo nation search engine and thus, find
your data and then download it.
Now, they had implemented something called "Mojo" (which, us BBS users
used to call "file credits"). Basically, you'd have 20 Mojo units --
and that would allow you to download 20 Megs worth of data from the
network. When you ran out, you'd have to upload some of your own data
for people to get.
Now, once you submitted data and somebody accessed it, the idea was that
it would split that data up into an associative map such that hunks of
data could be stored throughout the network in these client caches - and
then reassembled a piece at a time when you wanted to download it.
Let's say you have a 5 Meg mp3 file and put it up. The mojonation
client would split it up into 10 .5 Meg pieces. Each of those pieces
would be stored on other clients throughout the network and stored on
the back-end segment map. When I wanted to download 5meg.mp3 -- it
would find the 10 corresponding pieces and download them concurrently
from the fastest clients. It would then concatenate the files once it
had downloaded all of them and - viola - you have 5meg.mp3 in a portion
of the time.
The key here is that it was a media system as well, you could share
almost anything, including web sites. I've never used the service, but
it supposedly was an interesting technlogy. It may be pertinent to what
we're discussing here.
-Barry
Jonathan P Springer wrote:
>
> On Fri, May 03, 2002 at 05:25:28PM +0100, Chris Smith wrote:
> > On Friday 03 May 2002 16:52, Jonathan P Springer wrote:
>
> > Okay, I'm with you on this. I've assumed that the location of the service
> > would be known through some sort of discovery lookup. And now I think about
> > it, it does hold true that more than one agent could register a service with
> > the same name. How do we stop this?
> >
>
> For non-malicious cases, I think Java has the right idea. Use
> registered domain names as the root of the service name, then leave it
> to the owner of the domain name to manage the rest.
>
> In the case of the more malicious "duplicate registration,"
> I'm noodling over all sorts of possibilities. Much of this comes back
> to the "trust" discussions we had earlier. Some sort of digital
> signature game? "I know this is the service I want because when I
> combine the profile of the executable with a signed profile from Party
> X, whom I trust, I get a reliable answer." I can come up with ways to
> beat everything I've thought of so far. Suggestions, anyone?
>
> > > The key is that the physical location of the server never enters into
> > > the logical name of the service.
> >
> > Is that absolute, or a goal that we'd like to achieve? I still belive at
> > this stage that there should be some sort of service resolution service. In
> > fact there has to be one really, else (as in your example) server1 would not
> > know that server3 has the service it requires.
> >
>
> Two points:
>
> 1) I think using registered domain names as the base of the
> service name is not a bad idea; however, we can't assume that the
> service is physically located on a server in that domain. I find Java's
> namespace solution to be quite elegant, once one understands what's
> happening.
>
> 2) Given that a service can be uniquely identified and authenticated, I
> see no reason why a P2P-like web for service resolution is not viable.
> Finding "Jonathan's Service" is no more or less complicated than finding
> "jlo_nude.avi" in gnutella. Why centralize and create a point of
> breakage?
>
> > Got me thinking before the weekend! Damn!
> > Chris
> >
>
> Hey, I should be doing the thinking I'm paid for right now. This is
> hobby.
>
> -js
>
> > --
> > Chris Smith
> > Technical Architect - netFluid Technology Limited.
> > "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
> > E: address@hidden W: http://www.nfluid.co.uk
> > _______________________________________________
> > Developers mailing list
> > address@hidden
> > http://subscribe.dotgnu.org/mailman/listinfo/developers
>
> --
> -Jonathan P Springer <address@hidden>
> ------------------------------------------------------------------------------
> "A standard is an arbitrary solution to a recurring problem." - Joe Hazen
> _______________________________________________
> Developers mailing list
> address@hidden
> http://subscribe.dotgnu.org/mailman/listinfo/developers
From what I could see, it needs a lot of cleaning up to be *really*
accessible to scripting programmers ... but let's keep this going
somwhere (fast) !
Keep it moving ....
Gopal
--
The difference between insanity and genius is measured by success
From the sounds of what happened with introspector, its not clear what
direction GNU will go. Am I wrong?
I do believe that a bad decision on this could cripple GNU.
> -----Original Message-----
> From: Richard Stallman [mailto:address@hidden
> Sent: Monday, June 10, 2002 8:12 PM
> To: address@hidden
> Cc: address@hidden; address@hidden; address@hidden
> Subject: Re: My Favorite soapbox : XML linkage (was Re:
> [DotGNU]Jabber-thon)
>
>
> What if we want to create web services that can only
> be used by GPLed programs?
>
> In general, if you have implented just an arbitrary web service, I
> don't think there is any way to impose such a requirement. Perhaps
> you could require each user to sign a contract promising to use only
> GPL-covered software to access the system. I have a bad feeling about
> the idea of a web site's trying to restrict what software users can
> access it with, though.
>
> In some cases, if the web service in question consists of talking in
> an intimate way with some GPL-covered server software, we might try to
> argue that the client side and the server are really one program and
> the GPL applies to the client. However, in that situation it would
> be rather hard for that argument to prevail.
>
> It seems to follow that if DotGNU programs use Jabber in a
> straightforward way to communicate with each other, non-free programs
> will easily be able to talk with them. Is that a bad thing?
> I am not certain.
>
> We still need to be rethink the entire licensing issue
> for the creation of the GPL "viral" effect on the
> greater level.
>
> Please don't compare the GPL with a virus.
> It is misleading, and it is very unfriendly.
>
>
> _______________________________________________
> Developers mailing list
> address@hidden
> http://subscribe.dotgnu.org/mailman/listinfo/developers
>
From that big XML file, I extract the source code by
looking at the font and skip over line and page
numbers. The lines of documentation written before
and after the code are outputed.
you in the reduced XML that i call .cs even if it is
not cs yet you see the following structure :
(note that this is just an adhoc DTD, i dont know if
it works yet)
The lines of C# code are written here :
<!ELEMENT SRC (#PCDATA)>
<!ATTLIST SRC
font CDATA #REQUIRED <!-- the hex of the font-->
page CDATA #REQUIRED <!-- todo-looks like my regex
is broke -->
line CDATA #REQUIRED <!-- the line number -->
>
The BLOCK ELEMENT contains a contigious block of code
preceded by a line of doc (PREV) and followed by a
line of doc (FOLLOWING)
<!ELEMENT BLOCK (PREV,SRC+,FOLLOWING)>
<!ELEMENT PREV (#PCDATA)> <!-- contains the data
before the block -->
<!ELEMENT FOLLOWING (#PCDATA)> <!-- contains the data
after the block-->
<!ATTLIST PREV
state CDATA #REQUIRED <!-- name of the previous
state-->
>
<!ATTLIST BLOCK
state CDATA #REQUIRED <!-- a name of the state-->
>
<!ATTLIST FOLLOWING
state CDATA #REQUIRED <!-- a name of the state-->
font CDATA #REQUIRED <!-- the font of the state-->
>
Also note that the font dictionarys in the top of the
file test_twig.pl are keyed by filename passed as the
first parameter, I used txt ending on my computer, but
renamed the files to xml when uploading. The file will
have to be updated to reflect that change before it
can be used.
You will find the documents and the dtd for the xml on
the following directory
http://introspector.sourceforge.net/dotgnu/
Ecma-334.cs.gz - the cs xml
Ecma-334.pdf.gz -the pdf, it is funny that it cannot
be read by the original pdftohtml
Ecma-334.xml.gz - the low level xml
pdftoxml.dtd - the dtd for the low level xml
test_twig.pl - a program that reads the XML
Best regards,
Mike
=====
James Michael DuPont
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
From the given meta data we can implement all types of
tools including more stubbing for other language
interfaces, from the XML representation of the
functions we can create perl, python and and c
language bindings. csharp and csdoc really represent a
very good interface specification language, with much
more power than perl.
This could easily be turned into an perl module like
inline::specfication::csharp that just invoked csdoc
and parses the XMl. That will also start competing
with the non-free perlnet from active state.
This will allow a productive, and safe usage of the
csharp as a interface specification language.
I will be testing the csdoc some more and then will be
reimplementing the needed interfaces from the
introspector as a C#.
That will allow for my exisiting perl code to be used
behind the scene and slowly be replaced by c# code
while keeping the exact same interface.
I will be posting some example c# interfaces in the
next days, currently I have already Java code
generators that can be hijacked into spitting out c#.
I hope that you all like this idea, it will allow for
testing of the pnet tools and contribute to the dotgnu
project in a legal and social way.
best regards,
Mike
=====
James Michael DuPont
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
From what I've seen, ilasm is not able to produce java .class files,
and the -jvm switch inserts the jvm bytecode inside msil file format.
Did I miss the bytecode to .class feature available somewhere ?
Or does the pnet projet plan to use a java assembler ?
Regards
Sylvain
From that doc, I have compiled 1500 tests that produced 270 some object
files. But also parse dumps, rules and states. Csdoc and xmlified
errors.
For example the largest .o file is here:
http://introspector.sourceforge.net/dotgnu/testgen/tests/o/26.cs.o
Here is the source code for test 26
http://introspector.sourceforge.net/dotgnu/testgen/tests/26.cs
Here is the XML from the compiler, the parse state dumped
http://introspector.sourceforge.net/dotgnu/testgen/tests/26.cs.out
Here is the csdoc output, with the parse state added :
http://introspector.sourceforge.net/dotgnu/testgen/tests/26.cs.xml
Here are the compiler rules entered
http://introspector.sourceforge.net/dotgnu/testgen/tests/rules/26.cs.out.rules
Here are the compiler states entered for this code
E: Entered, R: RuleID, S: stack states
http://introspector.sourceforge.net/dotgnu/testgen/tests/states/26.cs.out.states
The source for the extractor is located :
Here is the font information that tells what is what:
http://introspector.sourceforge.net/dotgnu/testgen/FONTMAP.txt
Here is the full document with all debug information:
http://introspector.sourceforge.net/dotgnu/testgen/debug.xml
Here is the parser for the pdftohtml :
http://introspector.sourceforge.net/dotgnu/testgen/parse_pdftoxml.pl
Here is the parser for the bison xml dump and the cscc dump
http://introspector.sourceforge.net/dotgnu/testgen/parse_bison.pl
More to come, hope you find it interesting.
mike
=====
James Michael DuPont
http://introspector.sourceforge.net/
__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
From the consumer perspective it doesn't mean anything has changed about
MS invasion of privacy, cept that they are now sharing it with teh
government.
Ok, so now the US government will now also have access to people personal
use of the internet. And MS has to tell it's customers this?
No they don't!!!!!
They are not telling the consumers what's really going on here at all.
I have these things in my wallet called Credit Cards, I can use them to
buy stuff with and because I have more than one, no one credit card
company/bank really has access to such a complete record of my personal
spending, not to mention paying by cash/check too.
What the web browsing habits are really has absolutely nothing at all to
do with consumer spending habits, but a hell of a lot to do with profiling
people for what can only be criminal activity potential. And how long will
it be before the typical GNU developer fits the profile?
There's more:
Wasn't this made illegal in the doj case, for MS to do?
And if not, why not?
http://slashdot.org/article.pl?sid=02/08/10/1420208&mode=thread&tid=109&threshold=0
Isn't this really about .... well the same as the following? DRM and
Palladium.
Then:
http://slashdot.org/article.pl?sid=02/08/10/0056223&mode=thread&tid=99&threshold=0
Imagine that, MS astroturfing Free and Open Source Software
The important point in all of this is that more of the public is fooled by
it, than not.
How long is it going to be before a software company imposes restrictions
and control over hardware manufactures of such things as Motherboards and
drives?
The sooner a clear divide happens between use controlled systems and open
systems, the better. And what's that mean for projects like mono and
dotGNU?
Richard Stallman wrote the GPL....... So who's going to write the laws and
licenses that protect creativity and innovation?
MS seems to be shooting at the moon but is hitting the eagles and soon
there won't be any more eagles.
But then none of this is really any concern to this dotGNU.... is it?
---
Timothy Rue What's *DONE* in all we do? *AI PK OI IP OP SF IQ ID KE*
Email @ mailto:address@hidden >INPUT->(Processing)->OUTPUT>v
Web @ http://www.mindspring.com/~timrue/ ^<--------<----9----<--------<
From what I've read in your SEE document it looks like you've identified all
the important bits. In terms of protocol/transport the VRS is modular with a
well defined internal messaging API. Adding a Jabber transport mechanism is
as straightforward as writing something that listens for and understands
Jabber messages and can inject them into the VRS in the internal format. Easy.
You also need an equivalent that takes the resultant message coming out of
the VRS and fires it back as Jabber.
The equivalent in the SEE are seeport and seeuser.
I think we should all team up as there is already architecure in place for
the VRS that provides all the stuff the SEE is looking to require.
However, the architecure used by the VRS has not been ported to M$ as it uses
SysV IPC (message queues and the like) and shared memory. Something needs to
be done about that, any volunteers???? :o)
Okay you peer types.... comments?
Chris
--
Chris Smith
Technical Architect - netFluid Technology Ltd.
"Internet Technologies, Distributed Systems and Tuxedo Consultancy"
E: address@hidden W: http://www.nfluid.co.uk
From the pnet HACKING file:
The ECMA standards for C# and the Common Language Infrastructure (CLI)
can be found at the ECMA Web site:
http://www.ecma.ch/ecma1/STAND/ECMA-334.htm (C#)
http://www.ecma.ch/ecma1/STAND/ECMA-335.htm (CLI)
ECMA-335 is your best bet for answering your ldc.i4 and .maxstack
questions.
Cheers,
Rhys.
From what I found Google'ing, the setargv.obj file is shipped with MSVC is
what cygwin users use for this purpose. I was unable to find an equivalent
in mingw-land.
--Adity
From this the 'make it better' (including the morph into SEE and VRS) can be
done, but I'd suggest waiting to see what the architecture looks like before
starting to design code. By that I'm saying: As soon as you start designing
data structures you've definitely got to have some idea as to how system
components (whether they by functions, libraries or services) are going to
interact. This interaction idea may change once the community has started
playing with and using the DGEE. So I'm not really saying don't design code
- far from it! - but just that I expect the ground to shift in January.
Do you think that's a fair comment?
> All I can say is this , we're going to face a set of problems during the
> development of the .NET compatible version.... Some problems which are
> equally relevant for the better version .... I'd rather see how MS
> designers solved them before designing (or even reinventing) the
> solution... Most of these problems will be abstract , so a review of the
> API may be able to suggest a solution ...
Done more websurfing and reading that I can cope with!
The DGEE will illustrate (some of) the problems we're going to have, as I've
had to work around a few...
Can't wait to make it better!
I know it's a fundamental component of DotGNU, but I do thank everyone for
their interest and comment on this subject!
Cheers guys,
Chris 'in serious DGEE hack mode'
--
Chris Smith
Technical Architect - netFluid Technology Ltd.
"Internet Technologies, Distributed Systems and Tuxedo Consultancy"
E: address@hidden W: http://www.nfluid.co.uk
From this point onwards, pnet will only contain C source code, with
no direct dependencies on pnetlib.
If you are building a C# library or application (e.g. dotgnu.xml,
Qt#, etc), and you previously looked for pre-compiled assemblies
in "pnet/samples", then you will need to modify this. If however
you merely assumed that pnet had been "make install"'ed, then
you shouldn't have any problems.
Let me know if anyone encounters any problems. Hopefully ajmitch
and friends can update the debian package information to get the
assemblies from the new locations at install time.
We are now fully and cleanly bootstrapped: pnet bootstraps from gcc,
and pnetlib bootstraps from pnet. No magic binaries required.
Cheers,
Rhys.
From pnetlib I'm sending in DateTime.Ticks, I'm using plain Int64's
throughout the code. Once the ticks hit engine, they are then given to
support, which uses ILCLIToUnixTime to (as I supposed) convert them to =
epoch
based time, then I try and utime the file. Am I using ILCLIToUnixTime
incorrectly? Would it have something to do w/ cygwin?
Thanks!
--Aditya
From a Drew Cary show.... "we are not selling beer, but maps to a party
where the beer is free".
Perhaps the FSF need to better define and account for the membership fees,
as to what is done with such financial resources that really does help to
improve the software the member is using and being lead to believe they
are helping to support thru the membership dues.
I have never been against the FSF, but this membership thing, I can't help
but question exactly how is this helping to improve the development of GNU
software when those doing the developing may or not be formally associated
to FSF.
And what happens when software development finally evolves to a state that
enables most anyone to produce code within their available resources of
time...and regardless of their 40+ hour a week field of work... even when
it's not computer related? Don't be mistaken.....that is exactly where it
is headed..... autocoding. We all know better than to underestimate MS
stated intentions, or do we just think they are incompetent to market
anything of real user value?
Software is only as free as the users who use it, and are able to create
it. There is no exception to this.
---
*3 S.E.A.S - Virtual Interaction Configuration (VIC) - VISION OF VISIONS!*
*~ ~ ~ Advancing How we Perceive and Use the Tool of Computers!*
Timothy Rue What's *DONE* in all we do? *AI PK OI IP OP SF IQ ID KE*
Email @ mailto:address@hidden >INPUT->(Processing)->OUTPUT>v
Web @ http://www.mindspring.com/~timrue/ ^<--------<----9----<--------<
From my XML experience, text inside of a node is not a child of the node
itself. Rather, that node is of a different node type (thus specifying =
it as
'text node'), and the innerText variable is the string accessor. Please
correct me if I'm wrong. :-)
--Aditya
From the webservice author point of view it all looks the same, _except_
certain things can only be done with certain protocols. For instance, you
wouldn't do object serialisation over xmlrpc (i don't think).
In terms of property access, You'd never access a property directly anyway
but provide a method to do this. C# does this kinda automatically with the
set_ get_ syntax but you (the ws author) still need to provide the body of
these functions.
There may be a way to automate the publishing of 'properties' by providing a
special attribute for this purpose and having it do the necessary behind the
scenes. DotGNU specific yeah - but we want to make the world a better place.
Externally property access looks just like member access (and so it should!)
so Xml-Rpc and thus all protocols will be fine.
> > Though static properties should be settable , we have multiple VM
> > instances running and HTTP is stateless .. So
> >
> > a.set_X(42);
> > print a.get_X();
> >
> > might not always give 42 ...
Yes it will <grin>.
If you want state, then the webservice is built to provide state (ie the
state property of the WebService attribute is set). This has the effect of
making the object/class serialise itself on destruction (or at the first
point at which execution leaves the class). The object is serialised to some
central storage shared by the execution environment. This is all done for
you.
The original caller (who did the set) gets a session reference back. When
they do the get_ call, the session reference is sent too enabling the
execution environment to restore its state and satisfy the request.
However, there has to be a transparent and 'natural' way to pass state
tickets about. I'm not sure where MS puts these in the request/responses
with SOAP, they might be HTTP header items or in the SOAP data payload.
I broke out the company credit card today and bought some books, so I will be
dong some extensive reading on this topic!!
> if it gets handled by different VMs in the
> > DGEE message buffer/scheduler ?.. This is the case for php or mod_perl
> > or cgi unless they use an external data store ...
Bingo! It's the only way :o)
> That's why I'm pushing Jabber-RPC as primary DotGNU protocol, since it has
> state (I use the id attribute as session key and asume that RPC calls are
> blocking. This of course also means it will be rather hard to use DotGNU
> with Apache.
Ah, it "has state" in that it has somewhere to store the state key. Using
Jabber makes us no better off because we still have to arrange for state to
be restored on the back end. Jabber is a protocol that supports state
natively in it's protocol - so is probably *the* best protocol to use with
DotGNU state-friendly web services. There will be others too.
> > This might be something we could add as a Goldwater server like DGEE
> > or something like the age old database server :) ... (IMHO a simple
> > hashed dictionary would be useful for small stuff, and a database for
> > the big & bulky) ..
Needs a lot of thought. The first state stuff will probably be stored in bdb
on disk, or even via mysql (pretty easy to offer lots of options). bdb would
be good as its GPL and supports transactions, so we can be a bit clever in
assuring data integrity.
> > Remote updation is risky business ... atomicity,reliability and
> > concurrent writes are some of the "well studied" problems ... my textbook
> > instincts suggests liberal use of locks....
Cue transactions.
Hmm.
Interesting discussion :o)
I'll let you know what the books say!
(websurfing saw me wading through so much rubbish!)
Chris
--
Chris Smith
Technical Architect - netFluid Technology Ltd.
"Internet Technologies, Distributed Systems and Tuxedo Consultancy"
E: address@hidden W: http://www.nfluid.co.uk
From the dotgnu perspective, Java is on the radar big time.
The Dotgnu project is working on being able to compile Java to IL, and
we should be able to have Java code using the C# API.
The problem may be with the basic collection and uri classes,
we need to look into that in detail. There are a couple of ways that we
can try and align those interface, but in the end, people will not want
to learn a new api.
Many people use and like the Jena interface, and in some cases, it is
on the leading edge in RDF technology.
Please do suggest your times, otherwise, why dont we try and make this
weekends first dotgnu meeting. I am sure we can piggyback on top of
them There has been no confirmation from anyone on times.
The meetings are conducted via IRC in the channel
#dotgnu on irc.openprojects.net at the following
times:
Saturday 1000 UTC
Saturday 2200 UTC
The first is best for DotGNU members east of UTC
and the second is best for DotGNU members west
of UTC. Some of the key DotGNU members attend
both meetings.
The logs of #dotgnu are always available here:
http://ajmitch.dhis.org/dotgnu/
--- "Seaborne, Andy" <address@hidden> wrote:
>
> We'd like to be involved (even though we're in Java) but the
> timezones may
> intrude. We can always look at the chat logs.
>
> If there was a common processing model underlying such an RDF
> interface
> (nothing too complicated), this could be the style used by other
> languages,
> getting some alignment.
>
> Andy
>
> -----Original Message-----
> From: James Michael DuPont [mailto:address@hidden
> Sent: 11 February 2003 15:16
> To: James Michael DuPont; Stephen Compall; Jos De_Roo
> Cc: introspectors; Jos De_Roo; address@hidden;
> address@hidden; address@hidden
> Subject: Re: Call for a DotGNU/W3C RDF API (was Re:GPL relicense for
> Euler
> (was Re: call for alpha testers EulerSharp for dotgnu/pnet))
>
>
>
> Dear All,
>
> After many offline (chat) discussion about the idea of a DotGNU
> contribution of a RDF C# Interface, I would like to request that we
> have a chat meeting where all the interested parties sit down
> together.
>
> For me the best time would be on the weekend, on the 15th or the 22th
> of deb. But I noticed that the w3c meetings are generally during the
> week, that is a problem for many of the dotgnu members.
>
> What do you think? Who would like to be involved? I would like to get
> one member from the various rdf implementations there, the is the
> most
> important part. We need your support!
>
> please feed back,
> mike
=====
James Michael DuPont
http://introspector.sourceforge.net/
__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
From that we can generate most of the code needed.
mike
--- Peter Minten <address@hidden> wrote:
> Hi folks,
>
> Adam Ballai has taken up the job of Webservices WG leader. Now we
> only need a
> leader for the Business WG and we've got a complete DotGNU WG :-).
> Any
> volunteers?
>
> Greetings,
>
> Peter
>
>
> _______________________________________________
> Developers mailing list
> address@hidden
> http://www.dotgnu.org/mailman/listinfo/developers
=====
James Michael DuPont
http://introspector.sourceforge.net/
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
From the JLS link above, you can glean the rules for this.
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/
From everything I see, inner classes (actually, we're talking non-static
member classes, since inner classes also include anonymous and local
classes) are the same as nested classes except they have the outer
class' this pointer.
Expanding ^Tum's example, you can also do this:
public class Outer
{
int x;
public final String toString()
{
return "Woof!";
}
public class Inner
{
public final String toString()
{
return "Meow!";
}
public void Foo()
{
x = 10;
}
public void stuff()
{
System.out.println(this); // Meow!
System.out.println(Outer.this); // Woof!
System.out.println(x); // 10
}
}
}
>So the inner classes are inaccessible from outside ? (unlike nested
>classes ?)
They can be accessible from outside (public class Inner) - I think they're
like nested classes with the outer this pointer. ^Tum?
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/
From what I've seen, the DGEE has taken over as the primary
application execution environment, right? Have the other systems
(VRS, SEE, etc.) faded out / merged into DGEE?
Also, where could I find current documentation on the DGEE
architecture & functionality?
Just wanting to keep on top of current developments...
Good job all!
--eric
From a purist standpoint, however, [Ctrl+X] feels more semantically
equivalent to a [Backspace] than a regular textual "x". Your thoughts?
Getting back to the treatment of accented characters and a blatantly
non-purist handling thereof: what if you were to add a ToolkitKeys.Unspecified
(or ToolkitKeys.Special - I'm notoriously bad at names) which mapped
to Keys.None but nevertheless allowed you to determine whether KeyUp
and KeyDown events need to be generated? This would be a massive
shortcut/hack and if you're uncomfortable with it, you could also call
it a temporary solution. Just brainstorming here....
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/
From the output of pnetmark's "./configure --help":
--with-cscc use cscc to compile (Portable.NET)
--with-csc use csc to compile (Microsoft/Rotor)
--with-mcs use mcs to compile (Mono)
--with-ilrun use ilrun to run (Portable.NET)
--with-ms use native CLR to run (Microsoft)
--with-clix use clix to run (Rotor)
--with-rotor alias for --with-clix
--with-mono use mono to run (Mono JIT)
--with-mint use mint to run (Mono interpreter)
It is already possible to build and run with different combinations, even
without csant.
Cheers,
Rhys.
From Berkeley down to Rutgers, He's on my favorite terminal,
Any access I could get, He cats C right into foo,
But ain't seen nothing like him, His disciples lead him in,
On any campus yet, And he just breaks the root,
That deaf, dumb, and blind kid, Always has full SYS-PRIV's,
Sure sends a mean packet. Never uses lint,
That deaf, dumb, and blind kid,
Sure sends a mean packet.
He's a UNIX wizard,
There has to be a twist.
The UNIX wizard's got Ain't got no distractions,
Unlimited space on disk. Can't hear no whistles or bells,
How do you think he does it? Can't see no message flashing,
I don't know. Types by sense of smell,
What makes him so good? Those crazy little programs,
The proper bit flags set,
That deaf, dumb, and blind kid,
Sure sends a mean packet.
-- UNIX Wizard
security Consul Becker Jiang Zemin White House sniper morse kibo Pine
Gap diwn emc AFSPC Crowell militia Mafia
From which I assumed they were working on, or at least planning, a C++ =
compiler=2E But I'm not familiar with the Mono project so if Carl-Adam =
says they're not working on one then I expect he's right=2E
Regards,
Alex
| [Prev in Thread] |
Current Thread |
[Next in Thread] |