Ben- Although the front-end application is written in Flash, there are two Ruby pieces that need to be built: 1. CLI 2. Dependency Server The CLI should be easy and it can wait. The dependency server needs to be done soon though. Here's what I can think of as far as requirements: 1. Server is called mkdnd (Mockdown Daemon). 2. Manages library versions. 3. Libraries are in zip file format with an extension of ".mkz". 4. Library files should have a standardized name like "<name>-x.y.z.mkz". 5. Try to avoid manifest files. Derive info from package by filenames if possible. 6. Server needs to manage user accounts. 7. Upload new packages using POST /library 8. Retrieve specific library version using GET /library/<name>-x.y.z.mkz 9. Retrieve latest library version using GET /library/latest 10. Implement server in Sinatra. I'd like to enforce semantic versioning (http://semver.org) based on the internal changes to a package. For example, if no external interface is changed (i.e. bug fix), then only the patch number is incremented. If the external interface to a component is changed (i.e. property added), then the minor version is incremented. If the external interface is changed (i.e. component or property removed or renamed), then the major version is incremented. The exception to this would be that all beta versions of libraries (v0.y.z) are managed manually. It's basically going to look like RubyGems but for Mockdown. Let me know what you think. Ben
Sounds like a good plan to me. I'd be more inclined to use Rails 3 with Devise, since it takes care of sign ups, emails, etc. BTW http://clojures.org/ is an interesting lightweight package server, with its code online: https://github.com/ato/clojars-web I like its UI a lot. Ben On Wed, May 18, 2011 at 10:45 AM, Ben Johnson <benbjohnson@yahoo.com> wrote: > Ben- > > Although the front-end application is written in Flash, there are two Ruby > pieces that need to be built: > > 1. CLI > 2. Dependency Server > > The CLI should be easy and it can wait. The dependency server needs to be > done soon though. > > Here's what I can think of as far as requirements: > > 1. Server is called mkdnd (Mockdown Daemon). > 2. Manages library versions. > 3. Libraries are in zip file format with an extension of ".mkz". > 4. Library files should have a standardized name like "<name>-x.y.z.mkz". > 5. Try to avoid manifest files. Derive info from package by filenames if > possible. > 6. Server needs to manage user accounts. > 7. Upload new packages using POST /library > 8. Retrieve specific library version using GET /library/<name>-x.y.z.mkz > 9. Retrieve latest library version using GET /library/latest > 10. Implement server in Sinatra. > > I'd like to enforce semantic versioning (http://semver.org) based on the > internal changes to a package. For example, if no external interface is > changed (i.e. bug fix), then only the patch number is incremented. If the > external interface to a component is changed (i.e. property added), then the > minor version is incremented. If the external interface is changed (i.e. > component or property removed or renamed), then the major version is > incremented. The exception to this would be that all beta versions of > libraries (v0.y.z) are managed manually. > > It's basically going to look like RubyGems but for Mockdown. > > Let me know what you think. > > > > Ben >
Maybe the internal handling of the library versioning can be pushed to a gem. The thing I like about Sinatra is that it could be packaged as a gem with few dependencies and easily deployed if someone needed a local repository server. I could see doing a stripped down Sinatra version in the future but maybe we do a Rails 3 app for the main server to start. Do you know anything about authenticating with public keys? We may want to store a public key locally when users are authenticating and releasing via the CLI. Ben ________________________________ From: Ben Atkin <ben@benatkin.com> To: mockdown@librelist.com Sent: Wed, May 18, 2011 11:16:12 AM Subject: Re: [mockdown] Dependency Server Sounds like a good plan to me. I'd be more inclined to use Rails 3 with Devise, since it takes care of sign ups, emails, etc. BTW http://clojures.org/ is an interesting lightweight package server, with its code online: https://github.com/ato/clojars-web I like its UI a lot. Ben On Wed, May 18, 2011 at 10:45 AM, Ben Johnson <benbjohnson@yahoo.com> wrote: Ben- > > >Although the front-end application is written in Flash, there are two Ruby >pieces that need to be built: > > >1. CLI >2. Dependency Server > > >The CLI should be easy and it can wait. The dependency server needs to be done >soon though. > > >Here's what I can think of as far as requirements: > > >1. Server is called mkdnd (Mockdown Daemon). >2. Manages library versions. >3. Libraries are in zip file format with an extension of ".mkz". >4. Library files should have a standardized name like "<name>-x.y.z.mkz". >5. Try to avoid manifest files. Derive info from package by filenames if >possible. >6. Server needs to manage user accounts. >7. Upload new packages using POST /library >8. Retrieve specific library version using GET /library/<name>-x.y.z.mkz >9. Retrieve latest library version using GET /library/latest >10. Implement server in Sinatra. > > >I'd like to enforce semantic versioning (http://semver.org) based on the >internal changes to a package. For example, if no external interface is changed >(i.e. bug fix), then only the patch number is incremented. If the external >interface to a component is changed (i.e. property added), then the minor >version is incremented. If the external interface is changed (i.e. component or >property removed or renamed), then the major version is incremented. The >exception to this would be that all beta versions of libraries (v0.y.z) are >managed manually. > > >It's basically going to look like RubyGems but for Mockdown. > > >Let me know what you think. > > > > > >Ben