Just in case people are wondering, "Hmm, what's an interesting project I
could do with Rotor?", I came up with a few ideas that may or may not be
feasible--I'd love to do them but I have zero time.
1) Write an Apache module to host Rotor and managed-code modules, sort of a
servlet/ASP.NET mechanism. (Since ASP.NET isn't a formal part of the Rotor
release, you'd have to provide equivalent functionality.)
2) Take an exsiting open-source database (mSQL, for example) and host Rotor
inside of it, then hook it in to provide stored procedures written in C# or
JScript.NET.
3) Host Rotor inside an open-source web browser to provide for client-side
ASP.NET controls and downloadable managed components.
4) Build a RotorForms library wrapping around GTK or Qt.
5) Build a Gnome/CORBA P/Invoke capability into Rotor (just as the CLR has
COM P/Invoke).
and of course, the classic
*) Port Rotor to your platform of choice: Linux, BeOS, OS/2, Windows 3.1,
....
Just some thoughts.
Ted Neward
{.NET || Java} Course Author & Instructor, DevelopMentor
(http://www.develop.com)
http://www.javageeks.com/tneward
http://www.clrgeeks.com/tneward
----- Original Message -----
From: "David Stutz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 02, 2002 3:47 PM
Subject: Re: [DOTNET-ROTOR] Hosting a central CVS repository
> And FYI, we *are* bugfixing, doing some perf work, adding more test
> cases and docs, causing all-around havoc, and doing mysterious unnamed
> additional work (last one is for any conspiracy theorists on the
> list...)
>
> We're also continuing to pay attention to this conversation - I am
> personally very interested in Werner's ideas and in what people have to
> say about repository roles, willingness to help, etc.
>
> On a related note, those of you who are up to interesting stuff and feel
> like dropping me email directly describing what you are doing, where you
> think Rotor should go, or what your impressions of Rotor are, I'd be
> very interested in hearing from you!
>
> -- David
>
> -----Original Message-----
> From: Cristian Diaconu [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 02, 2002 3:36 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [DOTNET-ROTOR] Hosting a central CVS repository
>
>
> Whatever the solution is, I believe it has to take into account the fact
> that the Rotor team at MS is still evolving the code base. While this is
> the case, it makes full sense to avoid branching and to try and keep
> everybody working off the same images. The last time I brought this up,
> David Stutz said on this very subject:
>
> "The answer is yes: we are listening, and working on this."
>
> http://discuss.develop.com/archives/wa.exe?A2=ind0204b&L=dotnet-
> rotor&F=&S=&P=1240
>
> My thinking is that the more bugs/fixes we make available here, the more
> incentive we provide to the Rotor team to accelerate whatever plans they
> have to host a public central repository.
>
> However, based on the activity I've seen recently, that might not be the
> case too soon. (I'm not trying to take everybody here on a guilt trip,
> just stating a fact - I know everybody is busy with their day-time jobs
> - I am most of the time anyway, so no flames please :-) ).
>
> Cristian
>
> On Wed, 1 May 2002 17:59:44 -0400, Werner Vogels <[EMAIL PROTECTED]>
> wrote:
>
> >> There was a thread on this idea a while back--is there a centralized
> >> place by which to share these fixes? Has Microsoft come up with that
> >> yet, or is this list it, for the moment?
> >
> >We're willing to host this at Cornell. Actually we brought up the
> >server soon after the previous thread but got totally lost in the
> >quirks of running a CVS server under .net server. Win32 cvs clients are
>
> >OK but the authentication mechanism when running the win32 CVS server
> >are a royal pain. I'll see whether I can revive the effort.
> >
> >In the mean time, it is more important to get some organization going,
> >if we really want to host and manage updates to the source tree online.
>
> >We will need some organizational structure with people responsible for
> >certain modules, who will run tests, etc. before checking in changes,
> >etc. Update rules, etc. Anyone wants to take a stab at this?
> >
> >--
> >Werner
>
