Mercurial > hg > bitsyblog

comparison roadmap.txt @ 0:e3823be6a423

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
initial commit of bitsyblog, from https://svn.openplans.org/svn/standalone/bitsyblog/trunk/
author k0s <k0scist@gmail.com>
date Sat, 12 Sep 2009 16:06:57 -0400
parents
children
comparison
equal deleted inserted replaced
-1:000000000000 0:e3823be6a423
1 bitsyblog, middleware, and the roadmap to the future
2
3 the nice thing with working like software like bitsyblog is that the
4 intent of the software is clear. bitsyblog aims to provide a solution
5 for users to keep a log of their activities on the web. When thinking of
6 software in terms of the narrow intent of a component, it becomes much
7 easier to divine what sort of framework would look like around it and
8 how this framework might be applicable to other types of software.
9
10 Firstly, I noticed that the bitsyblog component app is not as small as
11 it could be. bitsyblog provides a multi-user solution to (personal)
12 blogging. This level of solution should exist, but thinking in terms
13 of components it is easy to see that users may want a personal blog
14 that is not multi-user. lammy wants a blog on his desktop computer.
15 When at his computer, he probably wants to be logged in all the time
16 (always accept connections from 127.0.0.1). He doesn't want other
17 people to be able to make a blog there. When not at his desktop, he
18 wants to be able to login and post through the web and maybe used the
19 blogme.py script too. In bitsyblog terms, '/lammy'
20 becomes '/' and all urls ('preferences', 'post', 'css/') become
21 relative to this. Doing this involves separating out the individual
22 blog components from the multi-user component and probably having
23 different .ini files from which to run paste.
24
25 I've also realized that the way I handle CSS is a solution to a
26 problem that has nothing to do with bitsyblog. The other items in
27 preferences ('date', 'subject', but not 'friends' which has to do with
28 roles) are about formatting the blog posts. The CSS is about themeing
29 pages which has nothing to do with blog posts. So what is needed is a
30 CSS component, which is possibly linked to from the preferences page.
31 Lets put this at '/lammy/css'. This pages may have the fields for
32 preferences, but also provides an interface for managing the CSS. A
33 user may want to delete CSS or edit them, render the current page with
34 a selected stylesheet or what's in the editor, or render an arbitrary web page
35 This is like CSS zen garden, but more interactive, and
36 (optionally) allowing the user to save the CSS and apply it to their
37 pages. I can also imagine, in a 2.0 version, an implementation that
38 allows permits transforming of CSS to suitable to theming a page with
39 a stylesheet intended for another page. One has a stylesheet with a
40 bunch of rules. Using javascript, one mouses over the DOM of the
41 other page. The rules are modified in order to applied to the
42 appropriate container on the page. This sounds much like what
43 deliverance is supposed to do, and maybe it could be utilized for this
44 intent, though perhaps the intents are different and its better not to
45 use it (to be investigated).
46
47 Both of the above components fall into a general pattern: there is a
48 component which is the multi-user blog manager. Lets call this
49 bitsyblog. There are microcomponents, the single-user blog (lets call
50 this microblog) and the CSS zen garden component which lets you play
51 with stylesheets (I dub thee samadhi). microblog and samadhi can live
52 on their own, in which case they live at '/', or they might be managed
53 by an external component -- microblog by bitsyblog, or samadhi
54 by...not really sure, either a microblog instance or bitsyblog. In
55 the latter case, they need to know where they live. I'm not sure what
56 provides the rewrite rule telling them where they live. Ian? Ethan?
57 There are a few configuration type details -- like auth, whether
58 samadhi needs to know about where to put these CSS files or how
59 bitsyusers can fetch them, but essentially if you give these the
60 appropriate path, they should be able to work relatively
61 independently.
62
63 In a different class of components are comments and tagging. While it
64 is easy to imagine bitsyblog managing comments and tags, it is also
65 fairly easy to see that these services really don't need to know what
66 is being commented or tagged on. For commenting, I imagine an app
67 similar to smokesignals, but with a different persistence model. Lets
68 call it commentator. Commentator is a javascript app with no
69 intrinsic URLs. Given a set of rules (for instance, "allow commenting
70 on <div>s with an id attribute) a block of text is shown as the last child
71 of each <div> (or conditionally on mouseover). This will initially
72 say something like "No comments | Add a comment" where each of these
73 do what you think ('N comments' displays the comments, 'Add a comment'
74 gives a textarea where you can say your mind). When a comment is
75 added, it is put in a database (presumedly SQL, though really on a
76 super-simple db is necessary) with the URL and/or id
77 as its key. When the page is loaded, the text of the page is examined
78 on response and the appropriate comments are displayed. It is also
79 necessary to have some sort of mapping optionally between URL and id
80 to another URI, as blog posts both are displayed as part of the user's
81 entire blog and also have a unique URL. Notice that nothing here is
82 particularly unique to blogs. Commenting on <div>s or <p>s in a wiki
83 page is essentially the same (though in this case, it might be better
84 to comment on the entire page, as these may not have ids and the page
85 can be editted all willy-nilly like that. Commenting on individual
86 <p>s and <div>s is, however, a really nice thing to have, so in a 2.0
87 type incarnation of commentator, this should be added regardless of
88 the difficulty). If bitsyblog was part of a
89 site with a wiki, then commentator could deal with them both nicely.
90 Optionally, one might specify the rule that if an item had comments,
91 it either could not be deleted or that an alert would pop up before
92 deletion with [Confirm] and [Cancel] buttons. This is easy to do if a
93 browser could do a DELETE request and things behaved all RESTful.
94 Otherwise, this would also be a non-trivial problem.
95
96 Tagging is very similar to commentator, though it might have a few
97 intrinsic URLs too. You specify a similar set of rules concerning
98 what can be tagged ("all <div>s with ids in /%(user)s/ and
99 /%(user)s/200*") and a method pointing the ids to URLs. Then you have
100 a database, which again is pretty simple and again in its simplest
101 form could be a dictionary. Though here, the tags are the keys and
102 the URLs are the values. You could also record number of tags per
103 item, specify whether non-authenticated members can tag, etc. As the
104 first or last child of each (say) <div>, you have what it has been
105 tagged with, maybe weighted by how many times it has been tagged. You
106 have a URL for searching by tags, maybe on a per-path basis ("I want
107 to see all the tags under /k0s that have been tagged with 'cats' and
108 'cute'"). You could also have a URL for the tag cloud. Again, what
109 is being tagged is pretty divorced from the tagging component itself
110 (lets call it tagit, unless that name is taken).
111
112 I have presented samadhi as being managed by bitsyblog or microblog
113 and commentator and tagit living outside of bitsyblog in the
114 middleware stack. I've done this because this "feels right" to me
115 right now, though I reseve my right to change my mind about it. The
116 thing I want emphasize is the difference in the two approaches:
117
118 * When a WSGI app is "managed" by another component app, the manager
119 has to know about the managed app and dispatch the appropriate
120 information (request, etc) to it, though in doing so it has the
121 opportunity to have more control over the URL structure and what the
122 component app does. It is also easier to return HTML this way.
123
124 * When a WSGI "app" is used as middleware and needs to markup the
125 returned page in HTML, this is conducive to using javascript in
126 order to insert nodes into the DOM dynamically, presumedly based on
127 some rule set. Alternatively, the middleware may decompose the page
128 with lxml and insert HTML where it needs to go that way. In this
129 approach, the middleware need not have a URL (this may be
130 preferable).
131
132 It is not necessarily clear to me at this time which approach is
133 better for different apps. I have put commenting and tagging in the
134 latter category because commenting and tagging on web pages seems
135 divorced (save by a rule set) from what is being commented on or
136 tagged. I have put microblog in the first category because it is
137 clearly in the same layer of software as bitsyblog, and some
138 management tasks will be necessary even for microblog. samadhi I put
139 in the first category as well (though I hesistate right now) because
140 otherwise the rewriting of URLs makes me nervous. Perhaps there is
141 need of a WSGI dispatcher that fetches apps based on some sort of rule
142 concerning the URL? Also, it seems
143 necessary to put the CSS on user data. This could also be
144 accomplished the other way: 1. abstract out members and roles
145 (teamroler?) and store the data (CSS, etc) on them here; 2. have
146 samadhi write a defined set of urls (how defined? not sure) including
147 the stylesheets that it knows about, presumedly putting the 'foo'
148 stylesheet at '/lammy/css/foo.css'. This still involves samadhi
149 knowing something about the url structure, and now it is dependent on
150 the user/role thing, though this could be a configuration option.
151
152 This is the middleware story. Other things could also be done
153 internally to bitsyblog and its supporting software to make the
154 experience more seamless.
155
156 I am bothered by the fact that the logic supporting the form and user
157 settings is somewhat divorced. Ideally, rendering the form should do
158 all the validation and return the settings in a sensible way to use.
159 I don't think this is hard -- the settings.py should just be
160 incorporated into markup.form. This goes some ways to reinventing
161 things like formencode and zope.schema, so if we can get these to do
162 what we want, maybe we shouldn't write our own. But at cursory
163 glance, formencode won't and zope.schema isn't easily usable outside
164 of zope. So maybe rolling our own isn't bad.
165
166 There's more middleware, but its hidden and is a bad coupling (that
167 is, the app will depend on the middleware unless its done cleverly).
168 The site nav does not appear on '/login' or '/join' (or any url not
169 specified internally to bitsyblog, for that matter). It would be
170 conceivable to have a SiteNav middleware that (either through
171 javascript or lxml decomposition) writes the site nav at the top of
172 the screen. bistyblog and bitsyauth would have to know about this
173 though, so that they could add the relevent links into environ. Maybe
174 this isn't horrible, but it seems so. Likewise, the site css doesn't
175 show up here. Should it? Is this another piece of middleware or part
176 of samadhi?
177
178 An important piece of middleware should involve members and roles. I
179 really don't want to write this one, but I would like to consume it.
180 It should live just inside of bitsyauth and make the users.py file
181 unnecessary. It might be better to sit on this one until last.
182
183 So should be bitsyblog 2.0.
184 There are a few other streamlining things (see the TODO.txt), but if
185 all of this was implemented, bitsyblog would be a rich web experience
186 that was highly componentized with each of the components doing one
187 thing well. Moreso, since coupling is avoided, save through
188 configuration, auth, and other loose links, each of these components
189 could be used independently of bitsyblog or turned off without
190 undesirable consequences.
191
192 At least as much as being a good blogging app, bitsyblog is about
193 elegant design and component architecture. This roadmap shows what is
194 possible in terms of having a fully functional blogging application
195 with middleware that can be used outside of just bitsyblog. To take
196 the other end of the spectrum, wordpress says "Hey, write plugins that
197 will make me work better." As a programmer, I really hate this
198 approach. If I write a commenting plugin for wordpress, then I have
199 just that. If I want to use it to comment on a wiki page, I'm out of
200 luck. If I write commenting middleware, then it can be used for any
201 WSGI app with minimal configuration. As a programmer, I generally
202 want the freedom to assemble a webapp however I want. With this
203 freedom comes some work, but for me its a worthy sacrifice. As a web
204 consumer, I understand that site administrators want out of the box
205 solutions. bitsyblog will offer this too. The default deployment of
206 bitsyblog will pull down commentator, samadhi, and tagit and have an
207 .ini file pointing to the appropriate factory to create the chain of
208 middleware to have all of these pieces in place. There is no contradiction.