Re: [DotGNU]Market research

[fitzix]

Myrddian wrote:
> 
> > I think it would be very important to do some market research
> > right now.  What functionality and benefits would the business
> > customers like to have?   Would functionality would the end
> > users find cool?
> >
> > How can we go about this?
> 
> Well, first of all we need a "test" platform to say this is what
> this framework can currently do. However I think market research
> is a side issue at the moment, we have to deal with other problems
> at hand, like building a theoretical framework.
> 
> WE should think that the people who would use this the most
> would be developers. AS for the user, this framework should be transparent
> and non-interfering (that is it does not require them to learn a new click
> mickey mousr interface or a "cryptic" command interface).
> I could be wrong my self :)
> 
> But it is useful, nonetheless to do some market research once we have
> a platform to test and promote.
> 
> 
> __________________________________________
> Myrddian <address@hidden(nospam)au>

Well, let's define "test platform"...

First of all, the authentication system server is key - this one's easy
because our test platform here would be various GNU/Linux servers.  I'm
loath to doing a windows port of this because of security and license
implications.

But, for the authentication system to work, there's going to have to be
an authentication client.  This is the tough part.  As long as the
information was to be kept on the auth server, we could have
(potentially) replaced any client with a web interface or another type
of low level client which simply contacted the auth server.  However, I
think that we all agree that this type of structure is a Bad Thing and
that we would prefer the user to have more control over the
authentication process...

Here's where the fun begins.  

Microsoft has an advantage over us at this point because they hold the
keys to the client OS.  This allows them to insert their authentication
and .Net framework at a low level and distribute the entire thing with
their OS.  This allows the .Net infrustructure to be entirely
transparent to the user.  Dotgnu, by it's very nature, will not be
entirely transparent to the user because we don't have access to the
source code - and because of the increased control we're going to have
to give the user.  This is not entirely a bad thing for most users. 
It's all about the amount of control that the user HAS to have.  Beyond
that, users will accept SOME configuration functions to fall to them. 
My solution to the client issue:  Create a client in a fast
cross-OS-capable language that has low level network functions.  The
client then interfaces with the server to do the authentication.  The
server acts as a buffer API to whatever Microsoft chooses to use
passport.com for, and the user's information lives on the client.  For
the sake of portability, some information may live - encrypted - on the
server for the person to be able to use the service external from their
home without having to input ALL of the information all over again.

That's just the authentication framework.  We're going to also have to
define a SOAP implementation (Ximian implementation may be good enough)
and there are already XML implementations out there.  

We're definitely going to have to create an API for all of this, and
this API is going to have to be cross-compatible.  Hence - I suggest
that each project be split, but that all client side parts of the
project be synced.  We're going to need a framework that compiles .Net
compatible programs, and then has a runtime environment for them.  We
need to do this even if we derive our interpreter out of another suite
of cross-compatible programming environments (like KAWA or Java). 
Personally, I think that we'd benefit from mixing as many languages in
there as possible.  We'll draw developers in from all areas in that way.

Looking at things this way, the entire project can be looked at as an
environment unto itself.  I think that this is the structure that we
should give it.  Rather than simply being a collection of modified
standard programs and libraries (although using as many of these as
possible to shorten our workspan is beneficial) we should consider this
to be one application made up of many.  Installing a dotgnu client on
your GNU/Windows/Mac system (A mac port can be an afterthought) would
allow a person to run any program that can be built within a dotgnu
framework.  Does everyone see where I'm going with this?