[BioRuby] Proposal: Bioruby modules (the bazaar)

Fri Jan 22 09:12:29 UTC 2010

Hi,

> As for the HTML portion, I see your point.
>
> * I'd like to hear comments from others.
> * How people like to render/visualize the BioRuby objects  
> (especially in HTML)?
> * I didn't mean to use the CGI class for HTML generation (I even  
> don't like that).

Perhaps the way to render the objects depends on both objects and  
purposes,
but if the object has a string representation, just showing them is  
perhaps
a good default. Also defining the way how to represent in HTML or any
other format for all classes comprehensively is too laborious as the  
first step
and a way to allow gradual growth of the codebase seems good.
It is the way flatfile parser grew to support many formats.

Thus, mechanism to do class specific conversion and default  
conversion for
non HTML aware classes is good.
Criticism on 'cgi' library for the default
conversion CGI.escapeHTML(object.to_s), especially for the name
is understandable.
There are already criticism on CGI.rb in itself
<http://jp.rubyist.net/magazine/?0023-Cgirb>
but there are no *standard* alternatives yet.
Perhaps we can just copy or rewrite the escapeHTML code
and make it any name that fits our purpose.

A drawback of having our escapeHTML code is that it could be
redundant in many cases where html generation is for CGI, and
we cannot get benefit from CGIAlt or any other compatible speedup
library on CGI, rewrite or extension with C. But I think this is
not a very large problem.

Making require 'bio' automatically loading cgi.rb is undesirable.
If the html code is not automatically loaded by require 'bio'
but loaded only another call require 'bio/html', then
I feel 'bio/html' loading cgi.rb is in a reasonable range.

Capability to use style instead of directly specifying color and
font is desirable since it could reduce the output size, and
possibly readability.
Nontheless, this is not mandatory and the first implementation
with direct specification is ok.

-- 
Tomoaki NISHIYAMA

Advanced Science Research Center,
Kanazawa University,
13-1 Takara-machi,
Kanazawa, 920-0934, Japan

On 2010/01/22, at 2:54, Toshiaki Katayama wrote:

> Dear Pj,
>
> I can understand your frustration and I like your idea of the
> 'module' system, as it reminds me the way how the Linux kernel
> tree is successfully maintained.
>
>> I wonder how many people on this list would contribute code if it was
>> more loosely organised.
>
> Indeed.
>
> However, I think our move from cvs to git was already a great step
> that it opened large opportunity to all those who want to participate
> in development. Before doing that, "open source" project not always
> mean "open to join" project.
>
> Now, everyone can easily fork the project and release their modified
> codes as you already done. So, we may able to evaluate from the  
> current
> situation that how many other people have tried.
>
> Anyway, it is still a difficult problem that who will decide and
> how to decide when to migrate the contributed code into the main tree.
> It might sound like a excuse, but I'm also suffering from the  
> difficulty.
> I also have several modules which are not yet contributed to the  
> main tree.
> For example, my SGE library for BioRuby (http://kanehisa.hgc.jp/~k/ 
> sge/)
> because I'm not sure it is general enough and where it fits.
>
>
> As for the HTML portion, I see your point.
>
> * I'd like to hear comments from others.
> * How people like to render/visualize the BioRuby objects  
> (especially in HTML)?
> * I didn't mean to use the CGI class for HTML generation (I even  
> don't like that).
> * The use of <p /> seems invalid in XHTML. See http://www.w3.org/TR/ 
> xhtml1/#C_3
>
>
> P.S.
> Once, I had developed a mechanism to integrate end-user code snippets
> in the BioRuby shell, called plugins. I wrote some plugins which  
> render
> a colored codon table, a formatted summary of sequence properties etc.
>
> If those and functions defined in your plugins can be easily  
> accessed by
>
>   puts Bio.your_function_name(options)
>
> or something like that, is it satisfy your needs?
>
> If so, we can consider to make a repository for such plugins and  
> bundle
> them in the BioRuby as well.
>
> Regards,
> Toshiaki Katayama
>
>
> On 2010/01/22, at 1:20, Pjotr Prins wrote:
>
>> Dear Toshiaki,
>>
>> On Thu, Jan 21, 2010 at 11:05:42PM +0900, Toshiaki Katayama wrote:
>>> I looked your code and had a feeling that we should use some
>>> template system.  If HTML tags are hard coded in the library as you
>>> did, it will be very hard to modify them by the user.
>>
>> Aren't we trying to overcomplicate things? This is an HTML generator
>> - in fact it is embedded HTML as I don't provide the <html>,  
>> header or
>> body parts. It can just be inserted into Rails, or whatever HTML
>> framework that is out there.
>>
>> Templating is just another abstraction. I don't intend to template
>> engines like Rails.
>>
>> Or, are you here merely referring to using the CGI class (or  
>> something
>> like that).  I guess I could do that, though I have trouble seeing  
>> the
>> benefits. It is just another way of writing HTML statements.
>>
>>> Besides, what version of the HTML specification did you have in
>>> mind?
>>> This is my first time to see the <p> tag is used in the form of  
>>> <p />. Is it valid?
>>
>> Yes. It is, in fact, XHTML.
>>
>>> I also think decorations should be separated to the CSS layer and  
>>> you should avoid to use the <font> tag, especially when you are  
>>> trying to distribute your code as a part of the library.
>>
>> We use hard coded colors. I could use CSS, but then you need to
>> provide a CSS file (or I need to hard code the header of the file).
>> That makes it (again) more complicated than necessary. Where do we
>> store the CSS file, how do we make sure the browser finds it? CSS is
>> really to adapt look and feel. If the output is meant to be fixed,  
>> why
>> make it flexible?  Besides all (future) browsers support the font  
>> tag,
>> as used. If that stops we could always adapt that source code.
>>
>>> As for the file location, I still like the way Naohisa has
>>> suggested.
>>
>> Alright. I can move the files, if that was all.
>>
>> However, my colored alignment is not going to make it into Bioruby
>> this way. There is always something wrong with my code, it appears.
>> Now I need to move file locations that have not really been decided
>> on; I need to template HTML - but we haven't decided how and it is
>> questionable; I need to use CSS, though I think it makes things worse
>> for users.
>>
>> Are we really sure you want to reject this code just because it does
>> not live up to everyone's current and future expectations? It may
>> still be useful to someone else, you know, it does not break anything
>> else, and can be improved in the future. Once we decide what we want
>> to achieve.
>>
>> The same really holds to my PAML branch and my GEO branch. Both
>> contain useful utilities for others to use. And now the alignment is
>> the third pending Bioruby branch.
>>
>> Can you imagine my growing frustration? Should this go into Bioruby,
>> or should I start another project, like others have done? Or stick it
>> into my existing biotools or bigbio projects? Just, so I don't have
>> the hassle?
>>
>> The way the Perl people handle it is by having independent modules.
>> Everyone owns his, or her, own module and Perl's CPAN acts more as an
>> aggragator. The advantage is that the environment is more dynamic.  
>> And
>> you really don't care what is inside a module. That is up to the
>> maintainer and his/her users.
>>
>> We could create independent BioRuby modules, which have their own git
>> repositories. When a module is nice enough to include in Bioruby make
>> it a git submodule - I use this technique for biolib - it will
>> register in the BioRuby repository. That way Bioruby still controls
>> what goes in a release. However, modules can be maintained for
>> experimental setups or private use. So my modules would go in
>>
>>  lib/bio/modules/paml
>>  lib/bio/modules/geo
>>  lib/bio/modules/htmlalignment
>>
>> each its own git repository.
>>
>> When one of those is 'strong' enough for main line you move it into a
>> different location in the main repository. Modules could even be
>> included in Bioruby releases.
>>
>> What hurts me now is that no one is going to use my code, since I
>> don't have the time to make it perfect, and it is hidden in my
>> experimental Bioruby branches. We should find a way to make
>> 'experimental code' available to the rest of the community. That way
>> we may also 'recruit' help to make the code more perfect.
>>
>> Make it easy to allow external modules to become visible through
>> Bioruby - that is a win-win, as well as a more bazaar-like approach
>> to OSS development.
>>
>> I wonder how many people on this list would contribute code if it was
>> more loosely organised.
>>
>> Pj.
>
>
> _______________________________________________
> BioRuby Project - http://www.bioruby.org/
> BioRuby mailing list
> BioRuby at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioruby
>