Awesome Austin. I've got some WordPress experience and I love that your theme is twentyonetwelve. I've been thinking about a NodeJS blog implementation and while I fought agains the "why Node?" question for a while I finally decided it was worth exploring. You've done a lot of the work already. I'm going to fork this maybe I can help.
Jerome On Tuesday, May 21, 2013 2:29:59 PM UTC-4, Austin William Wright wrote: > > Every so often (maybe twice a week in IRC) someone asks about a blog, > e-commerce, or content management system for Node.js. I feel compelled to > ask "Why Node.js", because it seems like one of those "I want to do it > because I can" rationales. Most people have that exact reason, and not much > else (that's not non-generic). But that's not to say no such reason exists. > > I had this idea of mine long before Node.js, so I have what I believe are > more practical reasons. A CMS is I/O heavy, not especially computationally > heavy. ECMAScript is a natural choice because it's prototype-based, > event-oriented, and of course, the language of the Web. A little while > after having been introduced to Node.js, I realized what Node.js was > perfect for, and started work somewhere around v0.4. > > Node.js (or any single-process paradigm) brings some design challenges. > For instance, in my application, I can't make the assumption that all > legitimate requests will only use a certain amount of memory — some > applications may require streaming an indefinite amount of data, for > instance. However, handling multiple requests per process means the total > resource usage of a single request can't be limited, at least by the OS. > The only solution I know of so far is, for every attacker, to make sure > that the non-generic attack of growing the process's memory to the point of > crashing is more expensive than a simple, generic DOS. > > I also don't want to make any assumptions how the application might be > used, I can't assume that only Jade or MongoDB will be used, for instance > (even if they are natively supported). > > Here's my implementation: Magnode.org <https://magnode.org/>. It's > designed as a framework, with a simple default application that tries to > cover most use cases. It uses many other libraries, particularly ones I had > to write, like rdf <https://github.com/Acubed/node-rdf>, > jsonschema<https://github.com/Acubed/jsonschema>, > and contenttype <https://github.com/Acubed/contenttype>. > > It works on the notion that a user requests a resource, the resource is > identified, then formatted into the requested Content-Type (via the Accept > header or the request URL), usually HTML or JSON, but depending on the > resource, you might also format e.g. a time series as an image, or a PDF > file. It's especially designed for graphs of data, like the Web (and > dereferencing nodes on it, hence the name Magnode). > > It's pretty capable right now: You start it up, run through a quick > web-based installer to initialize the configuration, then you can log in > and see a front page of blog posts (reverse chronological order), create > new posts, pages, add items to menus, create new menus, create users, and > such. With some coding, it should be relatively simple to create a new type > of output, maybe you want to generate an image from data for instance, this > should be possible with a fairly short file, maybe 50 lines (it involves > simply registering a function with a domain of whatever data type you want > to process, and a range of Document and image/png, or whatever media types > the output would be). > > While presently it only works with MongoDB, it's not designed for a > specific database (only about a dozen of 88 files are MongoDB-specific), > and I intend to support a number of data storage schemes. The next storage > scheme will be HTTP endpoints (effectively making Magnode an HTML frontend > to an HTTP API). Additionally I would like to see relational databases, an > IndexedDB-style database (where you query documents using specific indexes > instead of by their data), and an RDF graph database. > > Here are some features that work right now: > > > - Make lists and tables of content. The front page, by default, is a > list of blog posts. > - Revisioning of content - documents are only inserted into the > database by default. > - Custom schemas and content types, and custom templates for > formatting them. > - Resources are first-class: Most everything is an HTTP resource, > including blog posts, users, the content-types themselves, and even server > configuration if so desired. This means a single code base for doing > everything related to changing configuration and editing content. > - Pluggable user authentication and authorization. > - Content-Type negotiation can return any number of content types with > a Content-Location header, XHTML and JSON are supported natively. It also > supports most of the HTTP headers like Etag, Accept, If-Match, and > similar. > This means the server is naively a RESTful HTTP API. > > > Some use cases that I've designed for, but have yet to implement, are: > > > - A better UI for editing structured data and markup: Right now, many > operations like adjusting schema definitions requires editing raw JSON. > - Extensive caching of rendered resources. (Nonetheless, it still > performs faster and serves more requests than a comparable installation of > Drupal.) > - Straightforward editing of templates and themes, including > compression and aggregation of CSS and JS files. > - Self-registration and support for third party accounts (log in with > OpenID, etc). > - Content-Type aware formatting of error pages. > - User comments on resources > - OAuth (or similar) for delegating access of resources to third > parties (bearer tokens with sandbox permissions are already supported or > easily implemented). > - Editing and updating content in-line, and in real time (perhaps > integrate the MediaWiki > VisualEditor<http://www.mediawiki.org/wiki/VisualEditor>). > Magnode can update resources with a standard HTML POST form, or a PUT > request with a JSON document, but maybe also PUT raw HTML of the edited > page, parsing the HTML back into a database record. This would mean > editing > pages in-line with very little client-side scripting required, and no > significant requirement on the server either. > - Support more data sources as mentioned: relational (SQL), graph > (RDF), and resource (HTTP) databases. > > > One cool use case that I've already implemented is using Magnode as a > gateway that adds an HTML representation of resources to an otherwise JSON > HTTP API. With this, you can use your web browser as a console to interact > with the API endpoint. > > I'd really appreciate any help that people can offer. If you have MongoDB > running, take five minutes and go to the "Get Started" > page<https://magnode.org/download>, > then let me know what you think. The source is available through the > website or on GitHub <https://github.com/Acubed/magnode>. It is public > domain. > > Austin Wright. > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
