Mercurial > hg > bitsyblog
comparison roadmap.txt @ 0:e3823be6a423
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. |