Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Bricolage>
  3. devel
Re: 2009 Google Summer of Code - need YOUR comments asap on the ideas list!
phillip at communitybandwidth
Mar 10, 2009, 12:51 PM
Post #1 of 9 (4278 views)
Permalink
On 4-Mar-09, at 9:49 PM, David E. Wheeler wrote:

> So, what do you think are some good ideas for potential students?
> The Denison UI redesign, perhaps (have Matt, you can woo students!)?
> Add full-text search support? Add support for markup languages like
> Markdown and Textile? Bring on your ideas!
>
> Our idea list for past years is here:
>
> http://bricolage.cc/dev/summer_of_code/

Hi ho,

So here's an updated / compiled list based on "enhancement" tickets in
Bugzilla and recent chatter on the lists / IRC. I *really* need YOUR
help (yes, that's YOU!) to narrow this list down to projects that are:

* Realistically achievable in the GSOC timeline (~3 months)
* Still relevant and important to the Bricolage project at large
* Potentially well-suited to one of the mentors we have available
* Really fun and interesting for a student to work on full time for
the summer

And I'd really like to get comments back by COB today / tomorrow
morning so I can get the Ideas List page updated, and get our
application submitted before Friday.

I'd love to put them all into some kind of voting system and all that
jazz... but, in the interest of getting the page updated asap, I'll
just past the list here for your feedback, comments, and re-
categorization:

## Big projects

* Add a REST interface / API to Bricolage (http://www.gossamer-threads.com/lists/bricolage/devel/35637
)
* Port Bricolage to Windows.
* Port Bricolage to SQLite.
* Port Bricolage to run over the Muldis Rosetta ORDBMS framework.
* Full text searching (http://bugs.bricolage.cc/show_bug.cgi?id=816)
via Solr (http://www.gossamer-threads.com/lists/bricolage/devel/33734#33734
)
* Document conversion (http://bugs.bricolage.cc/show_bug.cgi?id=819)
* 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.
* Add support for user-selected input on textareas, e.g.:
MultiMarkdown, Textile, RichTech, etc.
* Add the ability to edit related assets directly from parent asset (http://www.gossamer-threads.com/lists/bricolage/users/33095#33095
)

## Medium-sized projects

* Improve the Bricolage Alerts system (http://bugs.bricolage.cc/show_bug.cgi?id=922
)
* Add reporting (http://bugs.bricolage.cc/show_bug.cgi?id=823)
* Creation of an API "mover" or action to allow Bricolage to more
easily publish to other systems that have Web / REST APIs.
* Improved media management (http://www.gossamer-threads.com/lists/bricolage/users/36365#36365
): resize, crop, zoom, etc.
* 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)
* Add Subversion integration for all assets. (http://bugs.bricolage.cc/show_bug.cgi?id=814
)
* Add WebDAV integration for all assets.(http://bugs.bricolage.cc/show_bug.cgi?id=815
)
* Modify version storage to store deltas instead of complete copies.
* 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.
* Publish queue improvements.
* Expiry templates (templates that get processed when a story is
expired)
* Add support for MultiMarkdown and / or other human-friendly text
markup languages / tools.

## 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.
* Improved user activity logging (http://www.gossamer-threads.com/lists/bricolage/users/36369#36369
)
* Improvements to the SOAP interface: access to more information via --
search
* Add human-friendly search options, e.g.: "Today" (http://bugs.bricolage.cc/show_bug.cgi?id=1315
)
* Add "search by contributor" field (http://bugs.bricolage.cc/show_bug.cgi?id=1321
)
* 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
)
* 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)

## 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.
* Add Site tagging and rollback as described in this to do. (http://bugs.bricolage.cc/show_bug.cgi?id=844
)

Thanks folks! Comments, feedback, and re-categorization asap if you
can. :-)

Phillip.

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com
Re: 2009 Google Summer of Code - need YOUR comments asap on the ideas list! [ In reply to ]
alex at gossamer-threads
Mar 10, 2009, 12:54 PM
Post #2 of 9 (4145 views)
Permalink
Hi Phillip,

> So here's an updated / compiled list based on "enhancement" tickets in
> Bugzilla and recent chatter on the lists / IRC. I *really* need YOUR
> help (yes, that's YOU!) to narrow this list down to projects that are:
>
> * Realistically achievable in the GSOC timeline (~3 months)
> * Still relevant and important to the Bricolage project at large
> * Potentially well-suited to one of the mentors we have available
> * Really fun and interesting for a student to work on full time for
> the summer

I'm a big fan of either:

> * Full text searching (http://bugs.bricolage.cc/show_bug.cgi?id=816)
> via Solr (http://www.gossamer-threads.com/lists/bricolage/devel/33734#33734)
> * Document conversion (http://bugs.bricolage.cc/show_bug.cgi?id=819)

and could help with either. Both of these would be achievable within 3
months.

Cheers,

Alex

--
Alex Krohn <alex@gossamer-threads.com>
Re: 2009 Google Summer of Code - need YOUR comments asap on the ideas list! [ In reply to ]
greg at node79
Mar 10, 2009, 3:02 PM
Post #3 of 9 (4138 views)
Permalink
On 10-Mar-09, at 3:51 PM, Phillip Smith wrote:

> * Improvements to the SOAP interface: access to more information via
> --search

Also, allow for working with contributors via SOAP. For that matter,
maybe break out "contributor" into a more advanced object that could
have a related story (bio), media, etc.

> * Expiry templates (templates that get processed when a story is
> expired)


Could we combine this with media templates too, if some work needs to
be done on getting that integrated and tested? (http://www.gossamer-threads.com/lists/bricolage/users/35396
) It starts to sound more like custom callbacks at this point, but
maybe there are some other kind of "templates" (reactivate template,
move into workflow template, etc.) that might also be useful?
Re: 2009 Google Summer of Code - need YOUR comments asap on the ideas list! [ In reply to ]
david at kineticode
Mar 10, 2009, 3:59 PM
Post #4 of 9 (4154 views)
Permalink
On Mar 10, 2009, at 3:02 PM, Greg Heo wrote:

>> * Expiry templates (templates that get processed when a story is
>> expired)
>
> Could we combine this with media templates too, if some work needs
> to be done on getting that integrated and tested? (http://www.gossamer-threads.com/lists/bricolage/users/35396
> ) It starts to sound more like custom callbacks at this point, but
> maybe there are some other kind of "templates" (reactivate template,
> move into workflow template, etc.) that might also be useful?

Event-triggered callbacks. Deets here:

http://www.justatheory.com/bricolage/design/tasks_jobs_actions.html

Best,

David
Re: 2009 Google Summer of Code - need YOUR comments asap on the ideas list! [ In reply to ]
david at kineticode
Mar 10, 2009, 7:04 PM
Post #5 of 9 (4138 views)
Permalink
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

> * 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.

> * 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.

> * 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.

> * 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.

> * 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.

> * 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

> * 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/

> * 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.

> * 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!

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
Re: 2009 Google Summer of Code - need YOUR comments asap on the ideas list! [ In reply to ]
phillip at communitybandwidth
Mar 11, 2009, 4:15 AM
Post #6 of 9 (4141 views)
Permalink
Very helpful, David. Many thanks! :-)

... going once, going twice...


On 11-Mar-09, at 12:04 AM, 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
>
>> * 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.
>
>> * 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.
>
>> * 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.
>
>> * 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.
>
>> * 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.
>
>> * 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
>
>> * 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/
>
>> * 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.
>
>> * 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!
>
> 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

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com
Re: 2009 Google Summer of Code - need YOUR comments asap on the ideas list! [ In reply to ]
ktm at rice
Mar 11, 2009, 5:59 AM
Post #7 of 9 (4139 views)
Permalink
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
Re: 2009 Google Summer of Code - need YOUR comments asap on the ideas list! [ In reply to ]
simonw at digitalcraftsmen
Mar 11, 2009, 6:12 AM
Post #8 of 9 (4138 views)
Permalink
On 10/3/09 22:02, Greg Heo wrote:
> On 10-Mar-09, at 3:51 PM, Phillip Smith wrote:
>
>> * Expiry templates (templates that get processed when a story is expired)
>
> Could we combine this with media templates too

Media Templates are basically done. It's mostly a case of removing stuff
that stops them running.

Paul's done most of the actual work, we use them in production but we've
lacked the time to write up tests and documentation so it's not in a
state to commit yet.

S.

--
Digital Craftsmen Ltd
Exmouth House, 3 Pine Street, London. EC1R 0JH
t 020 7183 1410 f 020 7099 5140 m 07951 758698
w http://www.digitalcraftsmen.net/
Re: 2009 Google Summer of Code - need YOUR comments asap on the ideas list! [ In reply to ]
phillip at communitybandwidth
Mar 12, 2009, 8:27 AM
Post #9 of 9 (4121 views)
Permalink
Thanks to all of you who provided feedback on the 2009 Google Summer
of Code ideas list. The current version (based on interest, priority,
and feedback) is now live at: http://www.bricolage.cc/dev/summer_of_code/


--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal