Re: Proposal for a introspector API into free software development toolchain

[James Michael DuPont <mdupont777 at yahoo dot com>]

Please excuse this cross posting, I know that it is not very good
manners.

I had replied this morning only to the introspector-developers list,
but
since we have a cross-post here, then I will respond one last time to
all. 

I would like ask the few if any who are interested in this discussion
to reply only to the introspector-developers@lists.sourceforge.net
list, because that way all the ideas are funneled into one spot. 

Everyone else, please excuse the wasting of bandwidth, just hit delete.
:)
David Sugar <dyfet@ostel.com> wrote: 
>  However, all such efforts must be undertaken with an extreme measure
> of caution.  

I aggree completly. For this reason, I am being carefull about what
license and data is used untill we can reach an agreement.

>I do encourage a great deal of review of the question and the legal
>foundations of  any specific license proposal before it is considered
>for actual use.

Yes %100. That is why I am not proposing a license just yet in
conjunction, even if I have been thinking and writing about it. 
I dont want to get into a legal discussion with this mail and the gcc
list does not want to be spammed with more legal questions. Let us just
say that there is sensitive and non-sensitive data that should be
treated with different levels of security. 

We should be able to explicitly mark such data as secure inside the
given program and have it treated as such by the meta-data extractor
tools. 

This making of private data with stricter licensing will be very
important for the next generation of DotGNU web services.
Authentication and ACLs will play a large role when programs just swim
through the sea of servers collection needed information.

Let me address this just on a technical level.

Basically, the idea behind the introspector is that
All types of data is stored about software on files in various formats,
all types of programs exist to process this information. 

The idea behind the introspector is to extract that data out of the
running tools via an XML Dumper patch into a common format
(XML/RDF/DAML) and then have all types of tools to collate that into a
repository of meta data. 

Instead of building tools to read the data, we change the existing
GPled tools to tell us about the data. This could be harmless and very
dangerous depending on the data involved, and a security concept is
needed to regulate the proliferation of data.

Remember in the old day, we had one executable, now we all have
bandwidth, ram and disk with very little limit.

This would then be presented back to the programmer, be
accessable at run time and even the end user might benefit. 

The user will be able to use various tools like EMACS, DIA, VCG,
MOZILLA, and more that are augmented to read and process this new
unified data format. 

The interesting work being done on DAML fits perfectly into the
meta-data and symantic repository concept.

This introspection means that a program "knows" about itself and its
environment, of course it is only possible and interesting for a user
to process this information intelligently, the program is just a
program that contains references to its meta data in a standard form.

My current version contains a meta data framework in perl and a XML
dumper for the gcc. The perl collects data from the gcc, stores the
metadata in  postgres repository , and then can
do code generation in SQL, PERL, and XML.

There is a lot of bits and bobs to the introspector, and now I am
finally putting it all together.

Also the first targets for the introspector were Perl, the gcc itself
and the DOTGNU PNET C# compiler Cscc. I have the XML dumps of those
projects metadata for a good point, that includes all public function
decls, data types, modules and identifiers.

For the sake of security and being social, the dumping of the full
function bodies will be disabled for the standard build. The is what
gets people upset because you can generate code with it.

I propose that we define a standard interchange format for this
meta data between the various free software development tools, this
will be centered around a "HARD" typesafe shell (IDL/C/C++/Java/C#) API
around a "SOFT" "XML/PERL/Python/Ruby/GUILE" scripting language,
and SQL/XML/GDMB data repository with a XMLRPC/SOAP/CORBA/RPC network
layer.

Like the ActiveStates perlnet interface specification layer, you will
be able to specify a typesafe interface into your scripting language
using an IDL like language, and then generate via a standard set of
tools an
shell to contain your softer data.

> BTW, would this follow the "Modest Proposal for a GNU infrastructure 
> license"?
I did not reference that for a reason, to avoid more legal talk on a 
development list. I am not a laywer. Let my tell you about the
technical side and give you a reference to how it was handled in the
old days of the GCC development.

The introspector in the spirit of the GNU manifesto,
this proposal is radical and questions many of the existing currents in
the GNU community. But it should be %100 GPL compatible.

The only issue will be to devise the proper security model in terms of
the DOTGNU framework. Some "DANGEROUS" data will not be published to
the public, but only to a registered set of users across a secure
interface.
This is a problem that will be address on the DOTGNU list, not on the
gcc list.

This is like how the GCC development used to take place, where only the
finished product was released. 

I you are interested in some history, check out this :
"Re: what DOES the GPL really say?" thread.
http://groups.google.com/groups?threadm=m2zpq0h7uc.fsf%40devo.ridgecrest.ca.us

BEGIN LEGAL SECTION
If we did something similar, we might have ability to distribute
"Dangerous" patches to a select few via SSH and some TERMS of Usage and
EULA agreement, I am not a lawyer, and the legal FAQ will be published
in a few weeks.

Even if the agreement says : "You can distribute this by the GPL, but
if you do we will stop the service and publically state that you as the
one who broke the aggreement".

But again, I don't want to talk about licensing here.
END LEGAL SECTION


The modest proposal for a RGPL is a legal and social discussion,

I want to avoid all futher license discussion on the development lists,
if you are interested in it :
my last update to the gnu.misc.discuss was here :
http://groups.google.com/groups?threadm=aes5e7%24uk6%241%40quimby.gnus.org
the thread on the FSL-dicuss here :
http://lists.alt.org/pipermail/fsl-discuss/2002-June/000508.html
And my blogger here: 
http://gccintrospector.blogspot.com/2002_06_23_gccintrospector_archive.html#78243629

Best regards,

Mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com