dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]Re: Developers digest, Vol 1 #404 - 8 msgs


From: Barry Fitzgerald
Subject: Re: [DotGNU]Re: Developers digest, Vol 1 #404 - 8 msgs
Date: Mon, 15 Apr 2002 17:14:00 -0400

John Rebbeck wrote:
> 
> With all this discussion would it be possible to create a new technology
> similar to SOAP but enough away that it is not illegal and then make it
> compatible with SOAP? This way it's not using SOAP (supposedly) but it does
> have the ability to? MS aren't going to use DOAP (DotGNU Object Access
> Protocol) so they will be limited, DotGNU will use both so will be the
> better option.
> 
> I may be way off track here but my limited knowlede of all this says this
> may work. What I said may still be illegal in terms of SOAP patents.
>

A SOAP compatibility layer would have to impliment SOAP itself, since
SOAP is really a standard.  Therefore, for true compatibility, if
essential SOAP components are covered by patents - you couldn't get away
from the body of the patent.

 
> Also...I think one of the most necessary things at the moment is an OS which
> has everything you want right in front of you, this is almost possible with
> web services and any problems that the OS has it can connect to the SS
> (Solution Server) and download the necessary information to fix it. Also,
> simple methods such as 'Plain Text Commands' could be used to let people do
> stuff by using simple commands ("I want to write a letter.", which could
> also be activated using speech recognition) and because it is connected to
> the web it can download updated PTC libraries, configurations, etc. to make
> it a self configuring and managing OS flawless.
> Could DotGNU do this?
> 

I was actually talking about this with somebody last night, only in the
context of RPM dependancy installation.  The premise was that if you get
an RPM that has dependancies, you'd build some kind of --getalldeps
feature into RPM and that would automatically use some form of
repository directory service.  Actually, this could be very well
abstracted on the client by creating say an rpmdepget program that
simply called the following RLS and handled the return transport:

example for the GIMP:

rls://rds.dotgnu.org/getrpmdeps?app="GIMP"&ver="1.2"

(rds == repository directory service)

Of course, this is the way that I would idealize the transport
interface.  There could, of course, be other ways to do this.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]