JGOFS/GLOBEC System Internals: Methods and objects

When we look at a typical data display via a web browser, we are seeing output controlled  by the  .htmlN  in the URL.  If we hit the  flat list  button, we get output controlled by the  .flatN  in the URL.  The software that handles the  .flatN  and the  .htmlN  is called  outer. Most methods (rs and defgb and others) are built with outer.  jgof_read.pl is NOT built with outer, so it cannot produce the output we expect from  .htmlN  or  .flatN . 
 

There is another, non-html, non-flat format.  It can be looked at with a browser by editing a typical URL to omit  .htmlN  and reloading the page.  Alternatively, you can 

        head some_file.jgof

All the JGOFS/GLOBEC software that uses objects for input reads this  ".jgof"  format.  For example,  rs takes an object as input.  join takes 2 objects as input.  jgof_read.pl  produces this  .jgof  format, so its output can be directly fed into  rs  and  join .  The "feeding" is done by using the "method-w-parameters" form of an object specifier.  defgb({}...)  and  jgof_read.pl(...)  are both examples of a "method-w parameters" form of an object specifier.  Thus, we can, say, 

        list "defgb(@whatever.ind)"
 

or
        list "join(object1,object2)"

because list wants an object specifier as input and the method-w-parameters is an object specifier. Looked at another way, an entry in a .objects file is an object specifier (via syntax like /globec/gb/test), but it's not the only kind of object specifier.  You'll probably recognize this method-w-parameters string as "the stuff to the right of the = in a .objects file".  That's exactly it - when you reference something in a .objects file, it is "turned into" method-w-parameters format. 
 

If we define an object using only  jgof_read.pl ; eg, 

        only_jgof_read=jgof_read.pl(data.jgof)

some things will work (such as list  /wherever/only_jgof_read)  but things associated with web display will not.