[Nitro] Up Dev Proc
transfire at gmail.com
Fri Apr 7 07:09:08 EDT 2006
On 4/7/06, Dimitri Aivaliotis <aglarond at gmail.com> wrote:
> On 4/7/06, TRANS <transfire at gmail.com> wrote:
> > On 4/7/06, Dimitri Aivaliotis <aglarond at gmail.com> wrote:
> > Don;t you hate it when someone spouts out an idea you've been quietly
> > working on? ;-)
> > > I was inspired while working on my web-based SpaceMerchant
> > > implementation, which is still not done because of this...
> > Hmm.... Care to collaborate?
> Sure. You'll have to wait on me, though. I'm not at the point yet
> where I have something workable. As soon as *something* works, I'll
> post to this list and ruby-talk.
K. But don;t keep me waiting too long, b/c I'm tempted to start such a
project myself --but I believe stongly in working together...
> > I'm curious. Is it an Open source project? How far along are you? What
> > features are you working on? And, you said "something very similar",
> > how is it different?
> Where do I begin? It is an Open Source project. I'm not very far
> along yet - my ideas, just a basic layout, and spec-ing out the
> classes I'll need. Features? Basically a source-tracking community
> application that can be used to keep track of itself and integrate
> into the "hosted" project as well. Hmm.. that's not too clear. In
> terms of REST, the following URIs will be accessible under the domain
> where the app is located:
> /docs -> api documentation
> /book -> user manual
> /code -> source code
> /chat -> user forum
> /news -> announcements, etc.
> /auth -> authenticator
> Each URI will understand GET, PUT, DELETE, etc. and act appropriately.
> To change the app, /code would be edited; checkins don't happen
> unless all tests pass; AJAX highlights the failing sections.
Nice. I like what you're planning.
> source files are actually saved with rdoc and rubyweb comments to
> facilitate Literate Programming; /docs, /book, and /code are just
> different views of the same files.
Oh, I like that. Add test/ to that too btw (something I already do
;-). Although there also has to be room for independent
> It's different from Trac or Rubyforge or similar things in that it is
> it's own RCS - not backed by CVS, SVN, Arch, Darcs, or anything else.
> I haven't worked all the details out yet, but strong cryptography and
> time-based editing sessions play a role.
Hmm... I encourage you not do this --at least not at first. It will be
much easier and quicker to get running by using "off the shelf" tech
here. A good RCS is not a simple thing to write (as least in my
experience, I've flirted with coding one). Use Darcs preferably, but
use one of these for the time being and come back to implementing your
own RCS later on.
> I'd be glad to discuss this more, but it may not be clear until I can
> get a demo ready. I'll see what I can get done this weekend - don't
> expect too much, though. It's a monumentous undertaking. Maybe I'll
> just have an introductory page up...
How about "bootstraping" the project. Start with the minimal
functionality to get a working system:
- user reg/auth
- code browser
- "wiki" code editor
- automated testing
- revision control
For now we don't need views. Tests can be in '=begin test' comment
blocks, and RDocs will quickly take care of themselves. It should be
pretty easy to add views in later.
Once these minimal requirements are in place, we can turn this very
project on itself, and pull it up by it's bootstraps!
When it's a bit more elaborate we'll turn it losse on Nitro and Og (by
then I imagine they'll be two independent repos).
How's that sound?
More information about the Nitro-general