ktm at rice
Mar 11, 2009, 5:59 AM
Post #5 of 6
(961 views)
Permalink
|
|
Re: 2009 Google Summer of Code - need YOUR comments asap on the ideas list!
[In reply to]
|
|
On Tue, Mar 10, 2009 at 07:04:40PM -0700, David E. Wheeler wrote:
> On Mar 10, 2009, at 12:51 PM, Phillip Smith wrote:
>
>> ## Big projects
>>
>> * Add a REST interface / API to Bricolage
>> (http://www.gossamer-threads.com/lists/bricolage/devel/35637)
>
> +1. I'd love to replace the awful SOAP interface.
>
>> * Port Bricolage to Windows.
>
> This likely is not a big project, as the hard bits (database and Apache2)
> are already done
>
For me this would be nice for testing/demo use, but as you mention the
big pieces are already working on Windows.
>> * Port Bricolage to SQLite.
>
> That would be cute. Probably not *too* big a project, unless someone was
> just getting started with databases. Perhaps it'd combine with porting to
> other databases, too, like Firebird.
>
My concern with this is the problems other DB apps. have mentioned in
their release notes about ONLY using the SQLite for testing and often
their are even caveats to that. Most problems with the SQLite backend
have answers like "Yes, it does not work...".
>> * Port Bricolage to run over the Muldis Rosetta ORDBMS framework.
>
> Yeah, that's a monster. And given that Muldis is still mainly a spec, it'd
> be pretty difficult, I think.
>
Not useful at all.
>> * Full text searching (http://bugs.bricolage.cc/show_bug.cgi?id=816) via
>> Solr (http://www.gossamer-threads.com/lists/bricolage/devel/33734#33734)
>
> This is probably my #1 preferred project, especially if it can be done in a
> pluggable manner, perhaps supporting both Solr and tsearch2.
>
+1
This would be my top project and ideally supporting both Solr and the
PostgreSQL full-text indexing (tsearch2 before 8.3). Having finally
added some full-text indexing to the RT incident tracking system, I
can attest to the ease of using full-text indexing in PostgreSQL. I
also spent some time yesterday familiarizing myself with Solr and
given its requirements in both software and hardware, it appeared
to be easier to use a separate PostgreSQL DB to add full-text indexing
to a MySQL/... backed Bricolage instance than to use Solr. We use many
tomcat based products here and the unexpected JVM tuning problems to
address resource issues are ubiquitous. Of course, "shell-ing out" to
another DB instance would only be neccessary if not using PostgreSQL
for a backend. My experience has been that I can show someone how to
setup a PostgreSQL instance in 5 minutes, given basic knowledge of
application installation, Windows or Unix. For JVM based products,
the learning curve is considerably steeper.
>> * Document conversion (http://bugs.bricolage.cc/show_bug.cgi?id=819)
>
> That's only as big as the number of documents we'd want to convert. But it
> would also require that there be some standardization of the names of
> things. If we standardize on HTML names (paragraph, header1, header2,
> ordered_list, list_item, etc), it'd work pretty well.
>
This may also be useful for moving external site content into Bricolage
for future management.
>> * Add support for concurrent checkout, diffs, and conflict resolution.
>> * Modernize/Simplify the installer (See Sam?s top-level design and the
>> Krang Farm for some ideas). It might make sense to work on Matchstick and
>> then port Bricolage?s installer to user it.
>
> Matchstick is dead, no? I'd be happy with a Module::Build-based installer.
> Then all the various scripts we have could be turned into modules which we
> plugin to the installer, and then write tests for them!
>
>> * Add support for user-selected input on textareas, e.g.: MultiMarkdown,
>> Textile, RichTech, etc.
>
> Probably not that big a project. The simplest way would be to add more
> WYSIWYG options, such as this Markdown editor:
>
> http://code.google.com/p/wmd/
>
>> * Add the ability to edit related assets directly from parent asset
>> (http://www.gossamer-threads.com/lists/bricolage/users/33095#33095)
>
> Eh. Does anyone really care about this?
>
>> ## Medium-sized projects
>>
>> * Improve the Bricolage Alerts system
>> (http://bugs.bricolage.cc/show_bug.cgi?id=922)
>
> This would best be done by taking my basic plans for how to create an
> event-triggered callback system. Alerts already do this, but it should be
> generalized to make it easy to develop plugins that can respond to any
> event. The alert system should be ported to the new approach.
>
> To me, this is a pretty large project, and would be an excellent one for
> GSoC. This is probably my #2 choice. Maybe #1.
>
+1
>> * Add reporting (http://bugs.bricolage.cc/show_bug.cgi?id=823)
>
> This would be a decent project. But does anyone really need it?
>
>> * Creation of an API "mover" or action to allow Bricolage to more easily
>> publish to other systems that have Web / REST APIs.
>
> +1
+1
>
>> * Improved media management
>> (http://www.gossamer-threads.com/lists/bricolage/users/36365#36365):
>> resize, crop, zoom, etc.
>
> +1. And as I said, perhaps merge stories and media as I've described
> elsewhere. Relevant docs here:
>
> https://svn.bricolage.cc/design-docs/trunk/Bricolage2/
>
> The TechnicalSpec is probably the most relevant. I seem to recall spending
> a lot of time on it at one point. Summary here:
>
> http://www.justatheory.com/bricolage/design/
>
+1
>> * Add a media type element constraint for related media elements and a
>> story type constraint for related story elements as described in this to
>> do (http://bugs.bricolage.cc/show_bug.cgi?id=987)
>
> +1. This would be a minor project. I would love to have it, myself.
>
+1
>> * Add Subversion integration for all assets.
>> (http://bugs.bricolage.cc/show_bug.cgi?id=814)
>
> Large project, and not gonna happen.
>
>> * Add WebDAV integration for all
>> assets.(http://bugs.bricolage.cc/show_bug.cgi?id=815)
>
> Cute idea. I'd welcome it, especially if documents were downloadable from
> the DAV server as something editable, like the bulk edit interface.
> Speaking of which, the bulk edit interface should probably be improved
> somehow. The use of the pod tag stuff is pretty ugly unless you're a Perl
> hacker. And even for me, now that I'm using Markdown a lot, I find POD to
> be unnecessarily verbose.
>
>> * Modify version storage to store deltas instead of complete copies.
>
> That'd be nice, but not really very important.
>
>> * Add support for JSP, ASP.NET, ERb, Cheetah, or some other templating
>> architecture. If the templating system isn?t written in Perl, you?ll be
>> able to borrow from the work done on PHP Sandwich the project started to
>> allow PHP templating in Bricolage.
>
> JavaScript templating!
+1 for JavaScript templating.
>
> http://search.cpan.org/dist/JavaScript/lib/JavaScript.pm
>
>> * Publish queue improvements.
>
> Such as? I mean, the whole thing could use a re-think, but what do folks
> have in mind?
>
>> * Expiry templates (templates that get processed when a story is expired)
>
> If we do event-triggered callbacks, this won't be necessary. Same for Media
> templates.
>
>> * Add support for MultiMarkdown and / or other human-friendly text markup
>> languages / tools.
>
> Dupe.
>
>> ## Smaller projects
>>
>> * More AJAXification of the Bricolage UI: useful keyboard shortcuts,
>> integrated spell-check, and the like. The sky?s the limit on the ideas
>> that could be applied here.
>
> +1 UI improvements are the #1 thing we can do to improve the product (#2
> would likely be a much simpler installer).
>
>> * Improved user activity logging
>> (http://www.gossamer-threads.com/lists/bricolage/users/36369#36369)
>
> We could add a link to the user manager now to an event log for a specific
> user. That would be very simple.
>
>> * Improvements to the SOAP interface: access to more information via
>> --search
>
> And objects not currently supported.
>
>> * Add human-friendly search options, e.g.: "Today"
>> (http://bugs.bricolage.cc/show_bug.cgi?id=1315)
>
> Full-text search!
>
>> * Add "search by contributor" field
>> (http://bugs.bricolage.cc/show_bug.cgi?id=1321)
>
> Full-text search!
>
>> * Bookmark favorite searches
>> (http://bugs.bricolage.cc/show_bug.cgi?id=1314)
>> * Form validation for elements (both server-side and client-side)
>> (http://www.gossamer-threads.com/lists/bricolage/users/36447#36447)
>
> Full-text search!
>
>> * External systems integration
>> (http://www.gossamer-threads.com/lists/bricolage/users/36344#36344)
>> * Workspace improvements (http://bugs.bricolage.cc/show_bug.cgi?id=1143)
>> * Add support for bulk upload of media documents as described in this to
>> do. (http://bugs.bricolage.cc/show_bug.cgi?id=985)
>
> All good.
>
>> ## I have no idea how hard these are!
>>
>> * Improve Unicode support in the Perl DBI. See this post for a high-level
>> description, and subscribe to the dbi-dev mail list for discussion.
>
> You forgot the link to the post. But this would be a good project for
> someone who wanted to work on a Perl-specific thing. It's C coding. Tim
> Bunce would have to buy-in and mentor.
>
>> * Add Site tagging and rollback as described in this to do.
>> (http://bugs.bricolage.cc/show_bug.cgi?id=844)
>
> Major project.
>
> HTH,
>
> David
My two cents.
Ken
|
