Brett's Blog

Saturday, July 04, 2009

Moving

Howdy all,

I think I'm pretty much going to move to http://brett-zamir.me for my own website, and http://blog.brett-zamir.me for my blog. I like the full control of not being dependent on any commercial site which may try to charge me later, add advertisements I don't want, etc. I'm not complaining about anything now (Blogspot is quite cool for the control it offers I think), but as I experienced with Yahoo where I used my email frequently enough that when I want to get access to my mails in a manner I want, I have to pay for their POP access. Not cool. So, having full control over my data (beyond the spammers in this world operating with impunity) is a good thing. I also have a smaller chance of having my personal site get blocked now that I am living in a country which will block a whole large website if a few pages on the article offend it. There's strength in diversity...

Wednesday, May 13, 2009

Mail & Unicode

I really hope that future versions of Thunderbird, etc. will have Unicode UTF-8 as the default for mail. Although there may be some legacy mail programs that do not support it, these need to get with the program... This won't affect English speakers really, so it might be easier for me to say, but I think one should just be able to send an email in any language or combinations of languages by default, as Unicode offers... I've changed my default Thunderbird option, but I don't think that alone will have much of an impact, even if a good number of other people do so too... Thoughts?

Friday, May 08, 2009

Gopher 2.0?

I designed some column browser code for browsing files (or any XML) with JavaScript. It needs some extending (e.g., to handle write operations like rename/delete/drag-and-drop move/etc.), but it basically works.

Now for browsing files over the web (or even representing local files), the question becomes what standard to use.

While the column browser can currently be used to browse through the tags of an HTML page, it'd be more useful I think if the now ubiquitous HTML (at least in XHTML form) could represent file hierarchies in a predictably browseable fashion, as the now long dying Gopher protocol does/did. Yes, we often like pictures and rich textual context to get to our pages of interest (as well as on our pages of interest), but often (like in Yahoo Directory), we just want to drill down quickly to our pages.

(Gopher inherently encourages such quick "drilling down", but I mention column browsers specifically because it enables a much faster navigation (most Gopher browsers to my knowledge use the file system equivalent of "icon view" where you have to click rather than being also able to use the arrow and letter keys on the keyboard and view more than one level of the hierarchy at a time, though it'd be cool to have "list/tree" view and "column view", to borrow other OS' terminologies).)

I've considered (and am still considering) XML formats like METS, but I wondered whether the <link/> and <meta/> facilities in HTML could be "good enough" given their familiarity to developers.


<html>
<head profile="http://tools.ietf.org/html/rfc1436"><!-- Gopher -->
<!-- we could also get fancier with the following and 
  use xml:lang, hreflang, charset, media, id -->
<link title="My first file in the directory" type="text/html" rel="next" 
href="http://example.com/some_link.html" />
<link title="My second file in the directory" type="text/plain" rel="next"
href="http://example.com/some_link2.txt" />
<link title="Another gopher2 'directory' file like this one" 
type="application/x-gopher2+xml" rel="next"
href="http://example.com/gopher2dir.html" />
</head>
<body>
    <p>Could have <a href=""/> links here for manual viewing, or just indicate 
this is a "Gopher 2.0" document</p>
</body>
</html>

So, the title attribute on <link/> gets used in place of the Gopher protocol's "User_Name" field, while Gopher's Selector, Host, and Port are discernible from the href attribute. The type attribute, meanwhile, gives the equivalent of Gopher's Type field.

That's it! (The only question really is whether we can overload the Gopher protocol for use in HTML as our own--I think it's better than adding my own custom URL for a profile, but maybe others disagree...)

We might be able to use meta tags if we wanted a more fail-safe way to translate into actual gopher files, and referencing each link's id:


<html>
<head profile="http://tools.ietf.org/html/rfc1436"><!-- Gopher -->
<meta name="Type" scheme="gopher" content="_1:h"/><!-- The first parameter 
is the link id below, while the part after the separator, here 'h', is 
the gopher type -->
<!-- Use scheme attribute to distinguish from any other profiles in 
use on the head? -->
<meta name="Type" scheme="gopher" content="_2:0"/>
<meta name="User_Name" scheme="gopher" 
    content="_1:My first file in the directory"/>
<meta name="Selector" scheme="gopher" 
    content="_1:/some_link.html"/>
<meta name="Host" scheme="gopher" 
    content="_1:example.com"/>
<meta name="Port" scheme="gopher" 
    content="_1:80"/>

<link id="_1" title="My first file in the directory" type="text/html" rel="next"
href="http://example.com/some_link.html" />
<link id="_2" title="My second file in the directory" type="text/plain" rel="next"
href="http://example.com/some_link2.txt" />
<link title="Another gopher2 'directory' file like this one" 
type="application/x-gopher2+xml" rel="next"
href="http://example.com/gopher2dir.html" />
</head>
<body>
    <p>Could have <a href=""/> links here for manual viewing, or just indicate 
this is a "Gopher 2.0" document</p>
</body>
</html>

...though I don't think this would really be necessary both because A) the <link/> can probably be readily translated into the equivalent fields (Type being a little more difficult), and B) Gopher as is is not being used much anymore.

(One should also be able to use <a rel="" href=""/> instead of <link/> since the profile on <head> would be good enough to indicate this was a different type of application (and would avoid duplication), but I used <link/> since they were all there in one place in the head for easy and fast retrieval, and one wouldn't need to necessarily show the links to HTML users (or choose how to do so).)

Then the question becomes to me (besides the profile choice mentioned above), what protocols (gopher2:...) and header types (application/x-gopher2+xml?) could be used to induce our Gopher-specific behavior in clients (such as Firefox which can have extensions made to handle such cases)... Of course, it'd be cool while in regular HTML mode to be able to opt to Gopher mode, but maybe some would like to recommend/force the Gopher type (especially if the HTML body didn't contain much or if the document was really intended to offer the fuller navigational facilities of our Gopher 2 and the author didn't want the user to be bothered to have to manually choose to start Gopher mode, even if the browser informed him of its Gopher 2.0 support).

I'm also interested in the following which also might depend on such a representation of files (and raise similar questions about protocols):

Links (e.g., using a custom protocol) which can indicate a package of files to download and store locally--e.g., for offline browsing--if they are not yet downloaded, and reference page numbers, special views of the data, etc. if it is already downloaded; this would work like HTML 5's offline applications, but would allow links which could refer to someone else's data--e.g., if someone downloaded a specific book (in XML or database form) from a particular site (or with a particular URN perhaps), one could click a link at another site to trigger a view of that same book (a specific page or paragraph range, a selection of font and colors, etc.). (Maybe this is like combining the cross-site Ajax with offline applications--let links be made to reference the same data in different ways?)

Navigable site maps, ala "Standard sitemap", but which can have links lead to browse other sites as well...

Both of the above would benefit from being able to represent a hierarchy of files...I wonder whether that could be solved by such as the following:


<html>
<head profile="http://example.com/our_sitemap_protocol">

<meta name="next" scheme="sitemap" content="level1:level2" />

<link title="Home page" id="level1" 
   href="http://mysite.com/home.html" />
<link title="Contact page" id="level2" 
    href="http://mysite.com/contact.html"  />
</head>
</body>
</html>

Sunday, April 05, 2009

XML DOM Support Test

After getting over a nasty cold, I'm just clearing off my old "shelf" so I can get back to work.

I don't have time to work on it now, but I wanted to put the beginnings of an XML Support Test (true XHTML form only at this point, so won't work in IE) here in case anyone were interested in building off of it, comment on it, etc., as well as for my own future reference.

Basically, inspired by web tests like Acid, I was hoping we XML and XHTML afficianados could stimulate better compliance from the browsers (including the "good" ones who normally try to adhere to standards but who still can fall short out of a perceived lack of community interest, or frankly their own occasional tendencies to "exceptionalism"), by having a test to highlight support for the DOM focused on XML features, up to DOM Level 3 (Acid seems to be covering a lot of the rest of the DOM, at least levels 1 and 2).

While the Acid test preparers have a high level of expertise both in awareness of the standards and creating a clever and appealing test output, for now at least, my own plan is just going to be to start with a simple chart, and hope that others may offer feedback and/or code as time goes on. No guarantees about how much time I may be able to give to this, etc., but I just wanted to take some step forward given my frustration at the seeming hopelessness of mere bug reports toward getting action on this front. As much as we may resist them, we all know that tests do inspire us, even normally fairly self-motivated people, and Acid is proof of that.

Again, I don't mean to be presumptuous to comparing my own test that I've barely begun to something like Acid (and which I'm not even guaranteeing I'll finish!), but just wanted to put this out there, both the little code I had as well as the idea...You are free to share or remix the code with attribution to "Brett Zamir" under the Creative Commons Attribution Share-Alike license. If we get things going, hopefully we can also choose a more interesting name than "XML DOM Support Test"... :)

Thursday, March 19, 2009

Observations on prototype

Came across the following interesting prototype behavior while trying to define methods on the class conditionally (for use in a large library where one might only wish to add certain groups of functions to the prototype, but which would be fine and memory-friendly for any instance which did want to use them).


function A () {
    // this.prototype.b = function () {alert('c');}; // this.prototype is undefined
    this.prototype = {b:function () {alert('c');}}; // rewrites prototype, but doesn't behave like a prototype, since by using 'this', we're creating our own copy; we can of course call items on the prototype but by dropping the word 'prototype'
    this.__proto__ = {c:function () {alert('d');}}; // Mozilla only; works as probably intended
    // A.prototype.b = function () {alert('e');}; // will work but requires hard-coding the class name here
}

var z = new A();
z.prototype.b(); // 'c'
z.c(); // 'd'
z.b(); // 'z.b is not a function' error

If your purpose in trying something like I was to conditionally add functions to the prototype (and thus for use by all instances), use of a static method on A() might be a better approach since it wouldn't involve building a large function into memory each time.

On another subject, here's I think a helpful way to distinguish between prototype and __proto__ in Mozilla:


function a () {
    this.b = function () {alert('our own b');};    
    this.__proto__.b(); // 'prototype b' (this only works in Mozilla)
    this.b(); // 'our own b' (we've covered b() on our prototype, though it is still there)
} 
a.prototype.b = function () {alert('prototype b');};

var z = new a();

or to build on this example, a little:


function a () {
    this.b(); // 'prototype b' 

    this.b = function () {alert('our own b');};    
    this.__proto__.b(); // 'prototype b' (this only works in Mozilla)
    this.b(); // 'our own b' (we've temporarily covered b() on our prototype)

    delete this.b;
    this.b(); // now we get 'prototype b' again
}
a.prototype.b = function () {alert('prototype b');};
 
var z = new a();

Sunday, March 08, 2009

Favorite bugs

No, don't worry, this is not an entomology post.

There is just some awesome work out there on open source projects, but often the bugs or missing features drive a person even more crazy to want to see them implemented (especially if you are a developer, as your feeling may be compounded by guilt for not learning enough to make the patch yourself).

Here are two missing features in two open source projects that I'm just dying to see implemented, and I invite anyone who feels the same to consider registering and voting on them.

(Note that feature requests on such trackers are often still described as "bugs".)

Songbird: Selectively disable rather than delete individual songs

Songbird is an awesome open-source music player, working similarly to iTunes, but missing one feature of iTunes and which is keeping me from moving my songs to it: Bug 15011, the ability to disable songs in the interface without deleting them.

External DTDs in Firefox/Mozilla

Another feature request I'm dying to see is for Firefox/Mozilla to support external DTDs over the web. DTDs, while a bit outdated for one of their purposes (schema validation, for the techies here), offer a simple way for a person to define shortcuts (potentially even for XHTML) which can be used in one's documents to:

represent an often larger piece of text

offer a means of translating a document--just swap the DTD, and you get the document in another language without having to repeat the code

represent characters in one's document such as © with a simple code like © instead of having to find and paste the symbol. While HTML already offers many such shortcuts without a need for a DTD, you cannot define your own, add to them, and if you are using another XML language (such as TEI used in classical or important religious texts, or DocBook for technical writing), you must use a DTD.

While this is easily doable by those who have a server and familiarity with scripting languages, for those who wish a simpler means of localizing or defining shortcuts, DTDs are the easiest means of doing so. We have the ability to define external stylesheets or scripts, but not for something so basic as this (text replacement). Moreover, many such documents already exist off the web, but some have, I feel, mistakenly argued that there is some dichotomy between on-web and off-web. If someone has a use for a document offline, why wouldn't one wish to have the ability to share it online, if so desired?

While it is possible to define these shortcuts at the top of each document (internal document subset), this reduces the usability of this functionality, as you do not have the option to reuse one frequently used file--you have to combine these into each of your documents rather than just making a quick reference to an external file.

Mozilla is already using external DTD's for translating its own documents, yet we cannot use these DTD's for remote XUL or other XML.

If you want this feature too in Mozilla, vote for it!!!!! Otherwise, there are many XML documents that one cannot put them as is on the web.

Monday, February 23, 2009

Cleaner private instance methods in JavaScript

Though the Relator requires extra code in places, the benefits are made up in readability in being clear what is private or not, as well as avoid needing the cumbersome 'this' everywhere (whose ubiquity makes its role less clear and also often requires adding a line to assign 'this' to 'that' anyways)

Here I point out a way to avoid needing to make a call() on each reference of a private instance method, again drawing from Andrea Giammarchi's approach to private methods, as I have also covered.

By assigning our static method to the scope of 'this' (as we do if we call call() on the method) and assigning the returned function to a private variable, we can get instance methods throughout our class. The disadvantage is that we add one function per instance (as with privileged methods), but the advantages are 1) the method is truly private, and 2) The syntax is cleaner. If you don't care about #2, just call a regular static method (but which can use 'this') with _privInstanceMethod.call(this, arg1, arg2);




var Constructor = (function () {var __ = Relator.$();

    // Harder setup, more memory, easier calling within the class
    function _setupPrivInstanceMethod (that) {var _ = __.method(that);
        return function () {
            alert(_.privateInstanceVariable);
        };
    }
    // Easier setup, and less memory, more complex calling within the class
    function _privInstanceMethod () {var _ = __.method(this);
        alert(_.privateInstanceVariable);
    }

    function Constructor () {var _ = __.constructor(this);
        _.privateInstanceVariable = 5; // Set up an instance variable to prove we're dealing with an instance method below
        _.privInstanceMethod = _setupPrivInstanceMethod(this); // add our instance's scope to return a function which is aware of the instance
    }
    Constructor.prototype = {
        constructor: Constructor,
        someMethod : function () {var _ = __.method(this);
            _.privInstanceMethod(); // '5'
            // more complex call (additional args would get added after 'this')
            _privInstanceMethod.call(this);  // '5' 
        }
    };
    return Constructor;
})();
var a = new Constructor();
a.someMethod();

Relator Zombies

I referred to the "Borg" option in the code comments for this post, in that we can call getAll() on the Relator for any object to access and manipulate any or all private instances variables for other objects already created. Thus, one can create an object, create another object, and then use the latter object to change data on all previous objects.

If we add a 'that' property to all of our Relator instances (easily achievable by adding one line to the middle of the "constructor" method we added for Relator in our last post):


constructor : function (that) {
    this.set(that);
    this.get(that).that = that;
    return this.get(that); // Assign to var _ = __.constructor(this);
},

we can then reference any public methods or members on all objects of this class (along with their private variables) after calling getAll() on the Relator instance:


var Person = (function () {var __ = Relator.$();
    function Person (name) {var _ = __.constructor(this);
        _.name = name;
    }
    Person.prototype.getName = function () {var _ = __.method(this);
        alert('My name is '+_.name);
    };
    Person.prototype.zombie = function () {
        var zombies = __.getAll();
        zombies.forEach(function(zombie){
            zombie.that.getName();
            // convenient syntax as we could also do something with zombie.name (or access other private instance variables we added)
        });
    };
    return Person;
})();

var bob = new Person('Bob');
var sarah = new Person('Sarah');
sarah.zombie(); // Alerts "My name is Bob" and then "My name is Sarah"

We could also have done the above by adding the following to the Relator class:


getInstances : function () {
    return Stack;
},

and then use the following method on Person (instead of the previous implementation):


    Person.prototype.zombie = function () {
        var zombies = __.getInstances();
        zombies.forEach(function(zombie){
            zombie.getName();
            // var z = __.get(zombie); // Getting a private variable now requires an extra step
            // alert(z.name);
        });
    };

This syntax is shorter to access the whole object and its public methods/members, but does not allow us to use the same syntax to access the zombies' private instances (unless we assign "__.get(zombie);" to a variable within the forEach and access the private data from there, as in the commented out text above).

Brett's Blog
Edit New

Saturday, July 04, 2009

Moving

Wednesday, May 13, 2009

Mail & Unicode

Friday, May 08, 2009

Gopher 2.0?

Sunday, April 05, 2009

XML DOM Support Test

Thursday, March 19, 2009

Observations on prototype

Sunday, March 08, 2009

Favorite bugs

Songbird: Selectively disable rather than delete individual songs

External DTDs in Firefox/Mozilla

Monday, February 23, 2009

Cleaner private instance methods in JavaScript

Relator Zombies

About

About Me

Support my Web Development Efforts

My categories

My pages

Links

Gift Wish Lists

Previous

Archives

Recommended Browser

Recommended books

Email Notification

Brett's Blog Edit New

Saturday, July 04, 2009

Moving

Wednesday, May 13, 2009

Mail & Unicode

Friday, May 08, 2009

Gopher 2.0?

Sunday, April 05, 2009

XML DOM Support Test

Thursday, March 19, 2009

Observations on prototype

Sunday, March 08, 2009

Favorite bugs

Songbird: Selectively disable rather than delete individual songs

External DTDs in Firefox/Mozilla

Monday, February 23, 2009

Cleaner private instance methods in JavaScript

Relator Zombies

About

About Me

Support my Web Development Efforts

My categories

My pages

Links

Gift Wish Lists

Previous

Archives

Recommended Browser

Recommended books

Email Notification

Brett's Blog
Edit New