Today this question came up in the IRC (moznet, #extdev). One of the add-on developers wanted to get the size of the page, either bytes or number of characters. The most obvious thing that came to my mind was progress listeners for definitive answers or the content length from the channel for not so critical scenario. But then he said he wants it for an already loaded page. And he further said that the information is already there somewhere as it is shown by the Page Info dialog (Right Click on a web page and select View Page Info). He was indeed right. Somebody in the code is already going through the trouble of calculating the data size and we can just re-use that. And I immediately started the quest to find that out.
As usual to figure out any browser component I opened up DOM Inspector. That tool is improving, which was against my earlier perception (Sorry Shawn Wilsher), though the highlighting part is still screwed up. Nevertheless, locating that particular label "Size" and the textbox in front of it containing the value was not difficult at all. I got the "id" of the textbox containing the size value. (Its "sizetext" :) ).
Next it was MXR (http://mxr.moziila.org/) in action. I did a text search for the id and got a bunch of results, one of which was pageInfo.js with this entry : line 489 -- setItemValue("sizetext", sizeText); . It is here. The very line made it apparent that it is the place where the value is being set and hence it is the place from where I can get to know how the value is being calculated.
Once I saw the code it was very clear and straight forward and pretty simple also. We have the URL. From the URL we get the cache entry for that URL. (Every cache entry has a key and that key is the URL - so neat). We try to get the cache entry from the HTTP Session first and if that fails we try FTP Session. The cache entry has the size as an attribute on itself, so its just getting that attribute value. DONE.
I am not sure how this will behave if we have disabled every type of cache. AFAIK, there will still be some in-memory cache as long as the page is still loaded. Probably good enough.
That was the end of a small but interesting quest. :-)
Showing posts with label IRC. Show all posts
Showing posts with label IRC. Show all posts
Wednesday, July 22, 2009
Saturday, June 27, 2009
Getting Open Source/Mozilla in my college - SJCE - Part I
Earlier I had written about my first Mozilla Education Status Call in which I mentioned my interest to bring Open source software in general and Mozilla in specific to my college, SJCE. Well, good news, it did not stop at that blog post. Actually speaking it had not started with that blog post either. It has been a long standing wish of mine, even from my college days when I participated in the Google Summer of Code 2007. (More about it here). Back then there were a lot of short-comings, both from my side and the institution's side to actually make this idea into reality. Nevertheless, past is past and no point in brooding about it now. The good thing is that now both I and my institution have overcome our short-comings and we have started working towards making that idea into a reality.
Now for some background aka story telling (which I like the most :) )
As stated earlier nothing happened about this idea when I was in my college. Then after passing out of the college and having worked in the industry for about 12-18 months it hit me, very hard, that I did not learn a lot of things during my life as an engineering student which otherwise would have helped me a lot in my professional life. Also I learnt that I was not competent enough as an engineering graduate as compared to some of my foreign counterparts and also those from some of the "famed premier" engineering institutions of the country. It was not just one thing or two, but I saw differences in many aspects, both theoretical and practical. Gradually it occurred to me that these two aspects are inter-related. Since we did not have proper practical experience and exposure to real world software development we never really appreciated the basic theoretical concepts of computer science, which formed our regular syllabus. Note that here I am saying "we" and not "I". This part of the story talks about the state of most of my classmates and that is the worst part. Nevertheless, the moral of the story is the good old philosophy of teaching that the theory and practice should go hand in hand.
Now there is another part to this story. Before I start with it let me tell you that whatever I am putting here is based on what I have perceived. I may be wrong, but I personally don't think so. And this is absolutely not about boasting about myself. So the other part of the story is that, my association with Open Source development communities, Mozilla to be specific, has greatly helped me in my professional life. I am not going to give examples, but it has really really helped me a lot. Also it has sort of put me ahead of several other capable classmates and most juniors of mine (with the difference being considerably more in the case of juniors). The only differentiating factor between me and them was my exposure to developing a real world application, Mozilla Firefox, and the various lessons that I have learnt by being a part of the global developer community. I am also certain that I could have been a much better computer engineer if I had started working with Mozilla at a much earlier stage, say 2nd year or early 3rd year of engineering and had dedicated more time to it. I still continue to learn a lot of general computer science and software development concepts (concepts not specific to Mozilla development) even now whenever I try to fix a Mozilla bug or even when I try to answer any query on the IRC, many a times even when I just observe few people conversing on the IRC.
Ok, enough of story telling. Now is the part for moral of the story. Here is what I inferred from these experiences:
1) Engineering students, specifically Computer Science engineering students, must get exposure to real world engineering (aka application development) to understand and appreciate the theoretical concepts they learn.
2) Open source software development communities provide a suitable environment for students to work with real world applications. Suitable in terms of - opportunities, cost, mentoring and certainly a few more good things also.
With these two points, it was clear to me that we badly needed open source education/exposure for students in my college. I knew that once this happened the possibilities were endless. Every time I heard/read about some of the classic Free Software implementations done at Universities abroad, I thought that our college can at least have several continuous contributors to currently existing open source projects, if not have creators of some totally new world class software projects. We could be having several different groups of students working of different types of software which operate at various levels (which translates to contributing to different open source software). Then they all could be interacting to help each other in troubleshooting problems. I thought of scenarios/discussions like this happening in the hostel corridors:
And so on.
Something like this is really possible. In fact many things much bigger than this are possible. But only if our students start working with and for open source communities.
So this set of thoughts made me work towards getting Open Source into my college. Now that's the background and the story. In the next part I will write about the first set of steps taken towards this, how many of them worked and how many were dead even before they started. And just FYI, the next post too will have some story telling (Obviously since this is just a record of my experiences and my (our) actions).
Now for some background aka story telling (which I like the most :) )
As stated earlier nothing happened about this idea when I was in my college. Then after passing out of the college and having worked in the industry for about 12-18 months it hit me, very hard, that I did not learn a lot of things during my life as an engineering student which otherwise would have helped me a lot in my professional life. Also I learnt that I was not competent enough as an engineering graduate as compared to some of my foreign counterparts and also those from some of the "famed premier" engineering institutions of the country. It was not just one thing or two, but I saw differences in many aspects, both theoretical and practical. Gradually it occurred to me that these two aspects are inter-related. Since we did not have proper practical experience and exposure to real world software development we never really appreciated the basic theoretical concepts of computer science, which formed our regular syllabus. Note that here I am saying "we" and not "I". This part of the story talks about the state of most of my classmates and that is the worst part. Nevertheless, the moral of the story is the good old philosophy of teaching that the theory and practice should go hand in hand.
Now there is another part to this story. Before I start with it let me tell you that whatever I am putting here is based on what I have perceived. I may be wrong, but I personally don't think so. And this is absolutely not about boasting about myself. So the other part of the story is that, my association with Open Source development communities, Mozilla to be specific, has greatly helped me in my professional life. I am not going to give examples, but it has really really helped me a lot. Also it has sort of put me ahead of several other capable classmates and most juniors of mine (with the difference being considerably more in the case of juniors). The only differentiating factor between me and them was my exposure to developing a real world application, Mozilla Firefox, and the various lessons that I have learnt by being a part of the global developer community. I am also certain that I could have been a much better computer engineer if I had started working with Mozilla at a much earlier stage, say 2nd year or early 3rd year of engineering and had dedicated more time to it. I still continue to learn a lot of general computer science and software development concepts (concepts not specific to Mozilla development) even now whenever I try to fix a Mozilla bug or even when I try to answer any query on the IRC, many a times even when I just observe few people conversing on the IRC.
Ok, enough of story telling. Now is the part for moral of the story. Here is what I inferred from these experiences:
1) Engineering students, specifically Computer Science engineering students, must get exposure to real world engineering (aka application development) to understand and appreciate the theoretical concepts they learn.
2) Open source software development communities provide a suitable environment for students to work with real world applications. Suitable in terms of - opportunities, cost, mentoring and certainly a few more good things also.
With these two points, it was clear to me that we badly needed open source education/exposure for students in my college. I knew that once this happened the possibilities were endless. Every time I heard/read about some of the classic Free Software implementations done at Universities abroad, I thought that our college can at least have several continuous contributors to currently existing open source projects, if not have creators of some totally new world class software projects. We could be having several different groups of students working of different types of software which operate at various levels (which translates to contributing to different open source software). Then they all could be interacting to help each other in troubleshooting problems. I thought of scenarios/discussions like this happening in the hostel corridors:
Student_1 and Student_2 are working on the Mozilla Download Manager (and here goes the conversation)
Student_1 : Hey, I want to test my new implementation for Mozilla Download Manager for HTTPS downloads. I am unable to configure my test server for HTTPS. You got any idea?
Student_2 : No dude, never done any server side stuff. Lets ask Student_3 from the Apache team.
Then Student_3 comes and sets up Apache for HTTPS within minutes (because that's day-to-day kind of stuff for him) and Student_1 continues testing his new implementation.
After some time:
Student_1 : Oh man, SSL handshake is taking too much time. I need to talk to Student_4, he knows the SSL library code base.
Student_2 : Yeah, I talked about that to Student_4. He is coming up with a patch to reduce the handshake time. It will probably be ready by tomorrow, I guess. Apparently it was a race condition causing the delays.
And so on.
Something like this is really possible. In fact many things much bigger than this are possible. But only if our students start working with and for open source communities.
So this set of thoughts made me work towards getting Open Source into my college. Now that's the background and the story. In the next part I will write about the first set of steps taken towards this, how many of them worked and how many were dead even before they started. And just FYI, the next post too will have some story telling (Obviously since this is just a record of my experiences and my (our) actions).
Saturday, August 30, 2008
offline cache discussion with campd
[ 2:20 am] <brahmana> hi all,
[ 2:20 am] <brahmana> Looks like my earlier question about offline cache got lost here...
[ 2:21 am] <brahmana> I read the HTML 5 spec and understood that the cache will be versioned and hence multiple versions of the same cached element will be present on the client's disk. Is that so?
[ 2:22 am] <campd> yeah
[ 2:22 am] <campd> as of 3.1
[ 2:22 am] <campd> in 3.0, there's only one version
[ 2:23 am] <brahmana> ok..
[ 2:23 am] <campd> brahmana: though they won't stick around long
[ 2:23 am] <brahmana> ok..
[ 2:23 am] <campd> brahmana: when you visit a page, it'll download a new version. Once any page using he old version is navigated away from, it is cleaned up
[ 2:25 am] <brahmana> campd, So everytime the user goes online and visits a website which has offline cache, the cache is refreshed provided no page is using the old cache.
[ 2:26 am] <campd> brahmana: sorta
[ 2:26 am] <campd> brahmana: every time they visit an offline cached website
[ 2:26 am] <campd> brahmana: it will check for a new version of the cache manifest
[ 2:26 am] <brahmana> ok..
[ 2:27 am] <campd> brahmana: if there's a new manifest, a new version of the cache will be created and fetched
[ 2:27 am] <brahmana> campd, ok.. answers my question fully..
[ 2:27 am] <campd> cool
[ 2:27 am] <brahmana> campd, However I have another question..
[ 2:27 am] <campd> ok
[ 2:28 am] <brahmana> Now is this cache application specific? As in if a image with the same src is referenced by two websites, the image will be cached separately for each webapp?
[ 2:28 am] <campd> yes.
[ 2:29 am] <brahmana> ok..
[ 2:30 am] <brahmana> campd, Will this offline cache in anyway affect the regular browsing when the user is online?
[ 2:30 am] <campd> if they're online, browsing an offline app, it will be loaded from the cache first
[ 2:30 am] <campd> it won't affect online browsing of non-offline pages
[ 2:31 am] <brahmana> ok..
[ 2:31 am] <campd> so if http://www.foo.com/offline.html is an offline app that references http://www.bar.com/another.html
[ 2:31 am] <campd> going to http://www.bar.com/another.html will NOT load it from the offline cache
[ 2:31 am] <campd> but going to http://www.foo.com/offline.html WILL be loaded from the offline cache
[ 2:32 am] <brahmana> okay..
[ 2:33 am] <brahmana> campd, Regarding the local storage, Can it be looked at as an extended form of what currently is cookie?
[ 2:34 am] <campd> kinda, yeah
[ 2:34 am] <brahmana> Is there any limit on the amount of data that each web-app gets on this local storage?
[ 2:35 am] <campd> yep
[ 2:35 am] <brahmana> Because the spec says that the web-app can use this to store user created _documents_
[ 2:35 am] <campd> 5 megs for the etld+1
[ 2:35 am] <campd> if the domain has the offline-app permission it gets more, but I forget the exact number
[ 2:35 am] <mconnor> campd: is that right? I thought I remembered some wacky combination thing
[ 2:36 am] <brahmana> oh.. ok.. thats pretty big space..
[ 2:36 am] <campd> (which I assume is the wacky combination mconnor's referring to ;))
[ 2:36 am] <mconnor> no
[ 2:36 am] <mconnor> it was something like "foo.bar.com can have 3 MB, and bar.com can have 2 MB" or something
[ 2:36 am] <mconnor> in whatever combination
[ 2:37 am] <mconnor> maybe that was the spec that got deprecated?
[ 2:37 am] <campd> I think right now it's just "5 for the whole etld"
[ 2:37 am] <campd> err, etld+1
[ 2:20 am] <brahmana> Looks like my earlier question about offline cache got lost here...
[ 2:21 am] <brahmana> I read the HTML 5 spec and understood that the cache will be versioned and hence multiple versions of the same cached element will be present on the client's disk. Is that so?
[ 2:22 am] <campd> yeah
[ 2:22 am] <campd> as of 3.1
[ 2:22 am] <campd> in 3.0, there's only one version
[ 2:23 am] <brahmana> ok..
[ 2:23 am] <campd> brahmana: though they won't stick around long
[ 2:23 am] <brahmana> ok..
[ 2:23 am] <campd> brahmana: when you visit a page, it'll download a new version. Once any page using he old version is navigated away from, it is cleaned up
[ 2:25 am] <brahmana> campd, So everytime the user goes online and visits a website which has offline cache, the cache is refreshed provided no page is using the old cache.
[ 2:26 am] <campd> brahmana: sorta
[ 2:26 am] <campd> brahmana: every time they visit an offline cached website
[ 2:26 am] <campd> brahmana: it will check for a new version of the cache manifest
[ 2:26 am] <brahmana> ok..
[ 2:27 am] <campd> brahmana: if there's a new manifest, a new version of the cache will be created and fetched
[ 2:27 am] <brahmana> campd, ok.. answers my question fully..
[ 2:27 am] <campd> cool
[ 2:27 am] <brahmana> campd, However I have another question..
[ 2:27 am] <campd> ok
[ 2:28 am] <brahmana> Now is this cache application specific? As in if a image with the same src is referenced by two websites, the image will be cached separately for each webapp?
[ 2:28 am] <campd> yes.
[ 2:29 am] <brahmana> ok..
[ 2:30 am] <brahmana> campd, Will this offline cache in anyway affect the regular browsing when the user is online?
[ 2:30 am] <campd> if they're online, browsing an offline app, it will be loaded from the cache first
[ 2:30 am] <campd> it won't affect online browsing of non-offline pages
[ 2:31 am] <brahmana> ok..
[ 2:31 am] <campd> so if http://www.foo.com/offline.html is an offline app that references http://www.bar.com/another.html
[ 2:31 am] <campd> going to http://www.bar.com/another.html will NOT load it from the offline cache
[ 2:31 am] <campd> but going to http://www.foo.com/offline.html WILL be loaded from the offline cache
[ 2:32 am] <brahmana> okay..
[ 2:33 am] <brahmana> campd, Regarding the local storage, Can it be looked at as an extended form of what currently is cookie?
[ 2:34 am] <campd> kinda, yeah
[ 2:34 am] <brahmana> Is there any limit on the amount of data that each web-app gets on this local storage?
[ 2:35 am] <campd> yep
[ 2:35 am] <brahmana> Because the spec says that the web-app can use this to store user created _documents_
[ 2:35 am] <campd> 5 megs for the etld+1
[ 2:35 am] <campd> if the domain has the offline-app permission it gets more, but I forget the exact number
[ 2:35 am] <mconnor> campd: is that right? I thought I remembered some wacky combination thing
[ 2:36 am] <brahmana> oh.. ok.. thats pretty big space..
[ 2:36 am] <campd> (which I assume is the wacky combination mconnor's referring to ;))
[ 2:36 am] <mconnor> no
[ 2:36 am] <mconnor> it was something like "foo.bar.com can have 3 MB, and bar.com can have 2 MB" or something
[ 2:36 am] <mconnor> in whatever combination
[ 2:37 am] <mconnor> maybe that was the spec that got deprecated?
[ 2:37 am] <campd> I think right now it's just "5 for the whole etld"
[ 2:37 am] <campd> err, etld+1
Wednesday, July 23, 2008
Discussion with biesi, bz and gavin about channel and tabId in #developers
brahmana wonders if biesi was able to examine the UML diagrams
[ 8:24 pm] <biesi> brahmana, sorry not yet
[ 8:24 pm] <brahmana> thought so..
[ 8:24 pm] <brahmana> biesi, anyways another quick question.
[ 8:25 pm] <biesi> brahmana, yes?
[ 8:26 pm] <brahmana> biesi, Can you please have a look at this one: http://wiki.mozilla.org/images/a/a0/Brahmana_URI_Loading_DocShell_Code.jpg -- Which would be the ideal point in the sequence to associate the tabId to the channel created.
[ 8:26 pm] <brahmana> ?
[ 8:26 pm] <brahmana> biesi, I want to know where I will have access to both of them.
[ 8:27 pm] <timeless> brahmana: pretty
[ 8:27 pm] <biesi> brahmana, um
[ 8:28 pm] <biesi> brahmana, nothing in that diagram has access to both :-)
[ 8:28 pm] <brahmana> timeless, thank you.. more here: http://wiki.mozilla.org/User:Brahmana/Netwerk_Docs (just in case)
[ 8:29 pm] <brahmana> biesi, ok.. so how much prior to webBrowser will I have to go to get a tabID ?
[ 8:29 pm] <biesi> brahmana, tabbrowser.xml
[ 8:29 pm] <biesi> its loadURI function or something like that
[ 8:29 pm] <biesi> brahmana, of course some things call loadURI on the web navigation directly...
[ 8:29 pm] <brahmana> biesi, yeah.. thats how I created that sequence diagram..
[ 8:30 pm] <brahmana> biesi, Can't I get hold of the tabID in C++ ?
[ 8:30 pm] <biesi> C++ has no concept of "tab"
[ 8:31 pm] <brahmana> But the <browser> present in each tab corresponds to one nsIWebBrowser, isn't it?
[ 8:31 pm] <brahmana> <browser> == the xul browser element
[ 8:35 pm] <biesi> brahmana, no
[ 8:35 pm] <biesi> there is no nsIWebBrowser in firefox
[ 8:36 pm] <biesi> that's only used for embedding
[ 8:36 pm] <timeless> unfortunately we don't use the same apis everywhere :(
[ 8:37 pm] <brahmana> oh man..
[ 8:37 pm] <biesi> brahmana, there is one docshell per tab
[ 8:37 pm] <brahmana> then the starting of my sequence diagram is wrong..
[ 8:37 pm] <biesi> if that helps you
[ 8:37 pm] <brahmana> yeah.. I am aware of that..
[ 8:38 pm] <brahmana> and I thought it was nsWebBrowser that held a reference to a docShell and made calls on the docShell
[ 8:38 pm] <biesi> ah, no
[ 8:38 pm] <brahmana> But as it appears firefox does not use nsWebBrowser itself...
[ 8:38 pm] <biesi> the browser holds the docshell directly, I believe
[ 8:39 pm] <brahmana> you mean the xul browser ?
[ 8:39 pm] <biesi> yeah
[ 8:39 pm] <brahmana> What C++ object does that map to?
[ 8:39 pm] <brahmana> something under widgets?
[ 8:39 pm] <biesi> the xul browser?
[ 8:39 pm] <brahmana> yeah
[ 8:40 pm] <biesi> um
[ 8:40 pm] <biesi> some xul magic
[ 8:40 pm] <biesi> nsXULElement.cpp perhaps
[ 8:40 pm] <brahmana> oh.. let me see
[ 8:40 pm] <biesi> via the boxObject maybe?
[ 8:41 pm] <biesi> but note that the <browser> is mostly an XBL thingy
[ 8:41 pm] <brahmana> oh man.. this is getting heavily complex..
[ 8:41 pm] <timeless> it really is
[ 8:43 pm] <brahmana> Now the JS call: browser.loadURI() will be a call on the corresponding nsXULElement object, which actually holds a reference to the docShell. Is that right?
[ 8:45 pm] * brahmana requests to put aside the XPCOM stuff that happens in the above sequence..
[ 8:45 pm] <brahmana> sorry, the XPConnect stuff..
[ 8:46 pm] <gavin|> yes
[ 8:46 pm] <gavin|> though the nsXULElement isn't really involved
[ 8:46 pm] <gavin|> apart from being associated with the JS object that implements the XBL methods
[ 8:48 pm] <brahmana> gavin|, Can you please elaborate a little on your last statement..
[ 8:48 pm] <brahmana> ?
[ 8:49 pm] <brahmana> Or is there a doc that I can read up to orient myself a little before asking lots of questions here?
[ 8:49 pm] <gavin|> nsXULElement itself doesn't have anything to do with the XBL implemented methods
[ 8:50 pm] <gavin|> it's just a "container"
[ 8:51 pm] <gavin|> it's not really useful to say that you're interacting with a nsXULElement, because you're really interacting with an XBL bound node
[ 8:51 pm] <gavin|> and the XBL <browser> methods implemented in JS are what matters
[ 8:51 pm] <gavin|> not the nsXULElement class methods
[ 8:52 pm] <brahmana> oh.. ok. so the browser.loadURI() is (most probably) implemented in the JS itself. This JS object holds a reference to the docShell directly and thats how the calls are routed -- makes sense?
[ 8:53 pm] <gavin|> that's about right
[ 8:55 pm] <brahmana> now this XBL/JS implementation is present in tabbrowser.xml?
[ 8:56 pm] <gavin|> and browser.xml, yeah
[ 8:56 pm] <gavin|> the tabbrowser contains <browser>s
[ 8:57 pm] <brahmana> This is the one I should be looking at: http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/browser.xml , right?
[ 8:58 pm] <gavin|> yes
[ 9:04 pm] <brahmana> gavin|, ok.. i figured the exit point to docShell: http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/browser.xml#186 --
[ 9:04 pm] <brahmana> Now I want to get the tabId in which this browser object is, how would I achieve it?
[ 9:04 pm] <gavin|> brahmana: not sure what you mean by "tabId"
[ 9:05 pm] <brahmana> tabIndex, the index of the tab in the tabContainer
[ 9:05 pm] <gavin|> you have a reference to a <browser>, and want to find which tab it's in?
[ 9:06 pm] <brahmana> yes..
[ 9:06 pm] <brahmana> well actually I am inside the browser's definition itself..
[ 9:06 pm] <gavin|> I guess you you need to loop through tabs and compare against their .linkedBrowser
[ 9:06 pm] <gavin|> don't think there's a utility method to do that
[ 9:07 pm] <brahmana> ok.. let me see how I can accomplish that..
[ 9:08 pm] <brahmana> I am thinking this... for(i=0; i < this.parentNode.browsers.length; ++i) if(this.parentNode.browsers[i] == this) return i
[ 9:09 pm] <brahmana> that must work, isn't it?
[ 9:09 pm] <gavin|> probably
[ 9:09 pm] <gavin|> assuming this.parentNode is the tabbrowser
[ 9:09 pm] <brahmana> yeah.. I verified that..
[ 9:09 pm] <gavin|> though the "browsers" getter builds an array by looping through taqbs
[ 9:09 pm] <gavin|> so it would best be avoided
[ 9:09 pm] <gavin|> to avoid having to loop twice
[ 9:10 pm] <brahmana> oh.. instead we directly loop through the tabs..
[ 9:10 pm] <gavin|> yeah
[ 9:10 pm] <gavin|> http://mxr.mozilla.org/seamonkey/source/browser/base/content/tabbrowser.xml#1693
[ 9:11 pm] <brahmana> And if i change the XBL now, is there anything that I need to do during the build?
[ 9:11 pm] <gavin|> you just need to rebuild browser/
[ 9:11 pm] <gavin|> (or toolkit/ if you're touching browser.xml
[ 9:12 pm] <gavin|> why are you changing them, though?
[ 9:12 pm] <brahmana> ok.. thats great.. i can even go for a full build.. :-)
[ 9:12 pm] <brahmana> I want to associate every channel with the tab it is working for..
[ 9:14 pm] <gavin|> brahmana: is therea bug # for this?
[ 9:15 pm] <brahmana> gavin|, oh no.. there isn't.. I saw similar thing in Firebug, Cookie Manager and wanted to explore on that..
[ 9:15 pm] <brahmana> if by any means this is a desirable thing we can have a bug...
[ 9:24 pm] <brahmana> Is the code under xpfe/ still used?
[ 9:25 pm] <gavin|> some of it is
[ 9:25 pm] <brahmana> the window mediator?
[ 9:25 pm] <gavin|> yes
[ 9:26 pm] <brahmana> Along with the tabIndex I would also require some sort of window Id i guess, as tabIndices are not unique across browser windows, isn't it?
[ 9:26 pm] <gavin|> right
[ 9:27 pm] <bz> tabindices need not be unique within a single window either
[ 9:28 pm] <gavin|> er, why wouldn't they be?
[ 9:28 pm] <brahmana> oh.. well if we do not open and close stuff, they should be right?
[ 9:28 pm] <bz> because they're under the control of the page author?
[ 9:28 pm] <bz> And nothing prevents an HTML author from sticking tabindex="2" on every single node in the document
[ 9:28 pm] <gavin|> we're talking browser tabs
[ 9:28 pm] <bz> oh
[ 9:29 pm] <bz> nevermind, then
[ 9:31 pm] <brahmana> gavin|, And about the bug for the stuff I am asking, I assume this isn't really a desired feature, is it?
[ 9:31 pm] <gavin|> brahmana: I still don't really know what the feature is
[ 9:35 pm] <brahmana> gavin|, To observe requests for one tab in observerservice ... there is requirement for coupling tab index with the http channel....
[ 9:35 pm] <brahmana> And that is what I am trying to accomplish, associate the tabIndex with the channel..
[ 9:37 pm] <bz> brahmana: er.... you know the docshell involved in both places, right?
[ 9:39 pm] <brahmana> bz, yeah.. I was talking to gavin and others about the way browser interacts with docShell. But I did not fully understand your question.
[ 9:39 pm] <brahmana> browser as in the xul browser element.
[ 9:40 pm] <bz> brahmana: docshell is he guts of a browser
[ 9:40 pm] <bz> brahmana: the part that actually holds the web page, etc
[ 9:41 pm] <brahmana> bz, yeah.. that was evident from this one: http://www.mozilla.org/projects/embedding/docshell.html and also from the length of nsDocShell.cpp file..
[ 9:43 pm] <bz> ok
[ 9:43 pm] <bz> so you can get from a tab to a docshell
[ 9:43 pm] <bz> you can get from the channel to a docshell (usually)
[ 9:43 pm] <bz> then compare the two
[ 9:43 pm] <bz> for images you're out of luck
[ 9:45 pm] <biesi> brahmana, there can be a <browser> that's not part of a <tabbrowser>
[ 9:46 pm] <brahmana> bz, Whats special about the images?
[ 9:46 pm] <biesi> what's NOT special about images
[ 9:46 pm] <bz> brahmana: they don't so much follow necko rules
[ 9:46 pm] <brahmana> biesi, Are you referring to a situation with single tab?
[ 9:47 pm] <brahmana> bz, biesi yeah I had got the same statement when discussing about the request end notifications..
[ 9:47 pm] <biesi> brahmana, no, I'm referring to extensions or mailnews or whatever that doesn't support tabs
[ 9:47 pm] <brahmana> biesi, oh well.. that is probably not a problem. I don't think we would go beyond firefox.
[ 9:48 pm] <biesi> ok
[ 9:48 pm] <biesi> I have no idea what you're trying to do
[ 9:48 pm] * bz points to "extensions"
[ 9:48 pm] <bz> anyway
[ 9:48 pm] <biesi> I'm just saying, if you want to change browser.xml in mozilla.org
[ 9:48 pm] <biesi> 's repository, you can't assume that there's a tabbrowser
[ 9:49 pm] <brahmana> point fully accepted.. :-)
[ 9:50 pm] <brahmana> bz, I am not sure about getting to a docShell from a channel. Is there is straight forward way?
[ 9:51 pm] <brahmana> s/there is/there a
[ 9:54 pm] <brahmana> moreover the docShell will have reference only to one channel and I assume that is channel corresponding to the base document, i.e the main document request. Is that so?
[ 9:55 pm] <bz> brahmana: the docshell is the channel's loadgroup's notification callbacks
[ 9:55 pm] <bz> brahmana: generally
[ 9:55 pm] <bz> brahmana: we're talking about a channel having a reference to the docshell, not the other way around
[ 9:57 pm] <biesi> the load group has the channels/requests for all the loads
[ 9:57 pm] <biesi> except for iframes of course
[10:00 pm] <brahmana> biesi, bz.. a little out of the current discussion.. When the http-on-modify request is fired, will the connection be already set up? Is there a possibility to change the request URL in that event's listener?
[10:01 pm] <bz> "change" in what sense?
[10:01 pm] <biesi> the connection is not set up yet
[10:01 pm] <biesi> but you can't change the URL
[10:01 pm] * bz really wishes URIs were immutable and that channels' URI were readonly so people wouldn't ask questions like this
[10:01 pm] <biesi> the channel's URI IS readonly
[10:01 pm] <brahmana> ok.. :-)
[10:01 pm] <bz> ah, good
[10:01 pm] <bz> well, that URIs were immutable, then
[10:02 pm] <bz> I thought we were gonna do that for http sometime
[10:02 pm] <bz> flip the bit
[10:02 pm] * brahmana decides not to ask such questions to be compliant with bz's wishes..
[10:02 pm] <bz> (and see what breaks)
[10:02 pm] <biesi> oh we aren't? that sucks :/
[10:02 pm] <bz> well
[10:02 pm] <bz> we're not _yet_
[10:02 pm] <bz> I also wish URIs were immutable by default instead of the nsIMutable mess..
[10:02 pm] <bz> but then again, I could use a pony too
[10:02 pm] <bz> Or better yet, a kayak
[10:02 pm] <bz> it is?
[10:03 pm] * bz looks in his "to check in" folder
[10:03 pm] <biesi> there's so much stuff that I'd like to change if I could...
[ 8:24 pm] <biesi> brahmana, sorry not yet
[ 8:24 pm] <brahmana> thought so..
[ 8:24 pm] <brahmana> biesi, anyways another quick question.
[ 8:25 pm] <biesi> brahmana, yes?
[ 8:26 pm] <brahmana> biesi, Can you please have a look at this one: http://wiki.mozilla.org/images/a/a0/Brahmana_URI_Loading_DocShell_Code.jpg -- Which would be the ideal point in the sequence to associate the tabId to the channel created.
[ 8:26 pm] <brahmana> ?
[ 8:26 pm] <brahmana> biesi, I want to know where I will have access to both of them.
[ 8:27 pm] <timeless> brahmana: pretty
[ 8:27 pm] <biesi> brahmana, um
[ 8:28 pm] <biesi> brahmana, nothing in that diagram has access to both :-)
[ 8:28 pm] <brahmana> timeless, thank you.. more here: http://wiki.mozilla.org/User:Brahmana/Netwerk_Docs (just in case)
[ 8:29 pm] <brahmana> biesi, ok.. so how much prior to webBrowser will I have to go to get a tabID ?
[ 8:29 pm] <biesi> brahmana, tabbrowser.xml
[ 8:29 pm] <biesi> its loadURI function or something like that
[ 8:29 pm] <biesi> brahmana, of course some things call loadURI on the web navigation directly...
[ 8:29 pm] <brahmana> biesi, yeah.. thats how I created that sequence diagram..
[ 8:30 pm] <brahmana> biesi, Can't I get hold of the tabID in C++ ?
[ 8:30 pm] <biesi> C++ has no concept of "tab"
[ 8:31 pm] <brahmana> But the <browser> present in each tab corresponds to one nsIWebBrowser, isn't it?
[ 8:31 pm] <brahmana> <browser> == the xul browser element
[ 8:35 pm] <biesi> brahmana, no
[ 8:35 pm] <biesi> there is no nsIWebBrowser in firefox
[ 8:36 pm] <biesi> that's only used for embedding
[ 8:36 pm] <timeless> unfortunately we don't use the same apis everywhere :(
[ 8:37 pm] <brahmana> oh man..
[ 8:37 pm] <biesi> brahmana, there is one docshell per tab
[ 8:37 pm] <brahmana> then the starting of my sequence diagram is wrong..
[ 8:37 pm] <biesi> if that helps you
[ 8:37 pm] <brahmana> yeah.. I am aware of that..
[ 8:38 pm] <brahmana> and I thought it was nsWebBrowser that held a reference to a docShell and made calls on the docShell
[ 8:38 pm] <biesi> ah, no
[ 8:38 pm] <brahmana> But as it appears firefox does not use nsWebBrowser itself...
[ 8:38 pm] <biesi> the browser holds the docshell directly, I believe
[ 8:39 pm] <brahmana> you mean the xul browser ?
[ 8:39 pm] <biesi> yeah
[ 8:39 pm] <brahmana> What C++ object does that map to?
[ 8:39 pm] <brahmana> something under widgets?
[ 8:39 pm] <biesi> the xul browser?
[ 8:39 pm] <brahmana> yeah
[ 8:40 pm] <biesi> um
[ 8:40 pm] <biesi> some xul magic
[ 8:40 pm] <biesi> nsXULElement.cpp perhaps
[ 8:40 pm] <brahmana> oh.. let me see
[ 8:40 pm] <biesi> via the boxObject maybe?
[ 8:41 pm] <biesi> but note that the <browser> is mostly an XBL thingy
[ 8:41 pm] <brahmana> oh man.. this is getting heavily complex..
[ 8:41 pm] <timeless> it really is
[ 8:43 pm] <brahmana> Now the JS call: browser.loadURI() will be a call on the corresponding nsXULElement object, which actually holds a reference to the docShell. Is that right?
[ 8:45 pm] * brahmana requests to put aside the XPCOM stuff that happens in the above sequence..
[ 8:45 pm] <brahmana> sorry, the XPConnect stuff..
[ 8:46 pm] <gavin|> yes
[ 8:46 pm] <gavin|> though the nsXULElement isn't really involved
[ 8:46 pm] <gavin|> apart from being associated with the JS object that implements the XBL methods
[ 8:48 pm] <brahmana> gavin|, Can you please elaborate a little on your last statement..
[ 8:48 pm] <brahmana> ?
[ 8:49 pm] <brahmana> Or is there a doc that I can read up to orient myself a little before asking lots of questions here?
[ 8:49 pm] <gavin|> nsXULElement itself doesn't have anything to do with the XBL implemented methods
[ 8:50 pm] <gavin|> it's just a "container"
[ 8:51 pm] <gavin|> it's not really useful to say that you're interacting with a nsXULElement, because you're really interacting with an XBL bound node
[ 8:51 pm] <gavin|> and the XBL <browser> methods implemented in JS are what matters
[ 8:51 pm] <gavin|> not the nsXULElement class methods
[ 8:52 pm] <brahmana> oh.. ok. so the browser.loadURI() is (most probably) implemented in the JS itself. This JS object holds a reference to the docShell directly and thats how the calls are routed -- makes sense?
[ 8:53 pm] <gavin|> that's about right
[ 8:55 pm] <brahmana> now this XBL/JS implementation is present in tabbrowser.xml?
[ 8:56 pm] <gavin|> and browser.xml, yeah
[ 8:56 pm] <gavin|> the tabbrowser contains <browser>s
[ 8:57 pm] <brahmana> This is the one I should be looking at: http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/browser.xml , right?
[ 8:58 pm] <gavin|> yes
[ 9:04 pm] <brahmana> gavin|, ok.. i figured the exit point to docShell: http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/browser.xml#186 --
[ 9:04 pm] <brahmana> Now I want to get the tabId in which this browser object is, how would I achieve it?
[ 9:04 pm] <gavin|> brahmana: not sure what you mean by "tabId"
[ 9:05 pm] <brahmana> tabIndex, the index of the tab in the tabContainer
[ 9:05 pm] <gavin|> you have a reference to a <browser>, and want to find which tab it's in?
[ 9:06 pm] <brahmana> yes..
[ 9:06 pm] <brahmana> well actually I am inside the browser's definition itself..
[ 9:06 pm] <gavin|> I guess you you need to loop through tabs and compare against their .linkedBrowser
[ 9:06 pm] <gavin|> don't think there's a utility method to do that
[ 9:07 pm] <brahmana> ok.. let me see how I can accomplish that..
[ 9:08 pm] <brahmana> I am thinking this... for(i=0; i < this.parentNode.browsers.length; ++i) if(this.parentNode.browsers[i] == this) return i
[ 9:09 pm] <brahmana> that must work, isn't it?
[ 9:09 pm] <gavin|> probably
[ 9:09 pm] <gavin|> assuming this.parentNode is the tabbrowser
[ 9:09 pm] <brahmana> yeah.. I verified that..
[ 9:09 pm] <gavin|> though the "browsers" getter builds an array by looping through taqbs
[ 9:09 pm] <gavin|> so it would best be avoided
[ 9:09 pm] <gavin|> to avoid having to loop twice
[ 9:10 pm] <brahmana> oh.. instead we directly loop through the tabs..
[ 9:10 pm] <gavin|> yeah
[ 9:10 pm] <gavin|> http://mxr.mozilla.org/seamonkey/source/browser/base/content/tabbrowser.xml#1693
[ 9:11 pm] <brahmana> And if i change the XBL now, is there anything that I need to do during the build?
[ 9:11 pm] <gavin|> you just need to rebuild browser/
[ 9:11 pm] <gavin|> (or toolkit/ if you're touching browser.xml
[ 9:12 pm] <gavin|> why are you changing them, though?
[ 9:12 pm] <brahmana> ok.. thats great.. i can even go for a full build.. :-)
[ 9:12 pm] <brahmana> I want to associate every channel with the tab it is working for..
[ 9:14 pm] <gavin|> brahmana: is therea bug # for this?
[ 9:15 pm] <brahmana> gavin|, oh no.. there isn't.. I saw similar thing in Firebug, Cookie Manager and wanted to explore on that..
[ 9:15 pm] <brahmana> if by any means this is a desirable thing we can have a bug...
[ 9:24 pm] <brahmana> Is the code under xpfe/ still used?
[ 9:25 pm] <gavin|> some of it is
[ 9:25 pm] <brahmana> the window mediator?
[ 9:25 pm] <gavin|> yes
[ 9:26 pm] <brahmana> Along with the tabIndex I would also require some sort of window Id i guess, as tabIndices are not unique across browser windows, isn't it?
[ 9:26 pm] <gavin|> right
[ 9:27 pm] <bz> tabindices need not be unique within a single window either
[ 9:28 pm] <gavin|> er, why wouldn't they be?
[ 9:28 pm] <brahmana> oh.. well if we do not open and close stuff, they should be right?
[ 9:28 pm] <bz> because they're under the control of the page author?
[ 9:28 pm] <bz> And nothing prevents an HTML author from sticking tabindex="2" on every single node in the document
[ 9:28 pm] <gavin|> we're talking browser tabs
[ 9:28 pm] <bz> oh
[ 9:29 pm] <bz> nevermind, then
[ 9:31 pm] <brahmana> gavin|, And about the bug for the stuff I am asking, I assume this isn't really a desired feature, is it?
[ 9:31 pm] <gavin|> brahmana: I still don't really know what the feature is
[ 9:35 pm] <brahmana> gavin|, To observe requests for one tab in observerservice ... there is requirement for coupling tab index with the http channel....
[ 9:35 pm] <brahmana> And that is what I am trying to accomplish, associate the tabIndex with the channel..
[ 9:37 pm] <bz> brahmana: er.... you know the docshell involved in both places, right?
[ 9:39 pm] <brahmana> bz, yeah.. I was talking to gavin and others about the way browser interacts with docShell. But I did not fully understand your question.
[ 9:39 pm] <brahmana> browser as in the xul browser element.
[ 9:40 pm] <bz> brahmana: docshell is he guts of a browser
[ 9:40 pm] <bz> brahmana: the part that actually holds the web page, etc
[ 9:41 pm] <brahmana> bz, yeah.. that was evident from this one: http://www.mozilla.org/projects/embedding/docshell.html and also from the length of nsDocShell.cpp file..
[ 9:43 pm] <bz> ok
[ 9:43 pm] <bz> so you can get from a tab to a docshell
[ 9:43 pm] <bz> you can get from the channel to a docshell (usually)
[ 9:43 pm] <bz> then compare the two
[ 9:43 pm] <bz> for images you're out of luck
[ 9:45 pm] <biesi> brahmana, there can be a <browser> that's not part of a <tabbrowser>
[ 9:46 pm] <brahmana> bz, Whats special about the images?
[ 9:46 pm] <biesi> what's NOT special about images
[ 9:46 pm] <bz> brahmana: they don't so much follow necko rules
[ 9:46 pm] <brahmana> biesi, Are you referring to a situation with single tab?
[ 9:47 pm] <brahmana> bz, biesi yeah I had got the same statement when discussing about the request end notifications..
[ 9:47 pm] <biesi> brahmana, no, I'm referring to extensions or mailnews or whatever that doesn't support tabs
[ 9:47 pm] <brahmana> biesi, oh well.. that is probably not a problem. I don't think we would go beyond firefox.
[ 9:48 pm] <biesi> ok
[ 9:48 pm] <biesi> I have no idea what you're trying to do
[ 9:48 pm] * bz points to "extensions"
[ 9:48 pm] <bz> anyway
[ 9:48 pm] <biesi> I'm just saying, if you want to change browser.xml in mozilla.org
[ 9:48 pm] <biesi> 's repository, you can't assume that there's a tabbrowser
[ 9:49 pm] <brahmana> point fully accepted.. :-)
[ 9:50 pm] <brahmana> bz, I am not sure about getting to a docShell from a channel. Is there is straight forward way?
[ 9:51 pm] <brahmana> s/there is/there a
[ 9:54 pm] <brahmana> moreover the docShell will have reference only to one channel and I assume that is channel corresponding to the base document, i.e the main document request. Is that so?
[ 9:55 pm] <bz> brahmana: the docshell is the channel's loadgroup's notification callbacks
[ 9:55 pm] <bz> brahmana: generally
[ 9:55 pm] <bz> brahmana: we're talking about a channel having a reference to the docshell, not the other way around
[ 9:57 pm] <biesi> the load group has the channels/requests for all the loads
[ 9:57 pm] <biesi> except for iframes of course
[10:00 pm] <brahmana> biesi, bz.. a little out of the current discussion.. When the http-on-modify request is fired, will the connection be already set up? Is there a possibility to change the request URL in that event's listener?
[10:01 pm] <bz> "change" in what sense?
[10:01 pm] <biesi> the connection is not set up yet
[10:01 pm] <biesi> but you can't change the URL
[10:01 pm] * bz really wishes URIs were immutable and that channels' URI were readonly so people wouldn't ask questions like this
[10:01 pm] <biesi> the channel's URI IS readonly
[10:01 pm] <brahmana> ok.. :-)
[10:01 pm] <bz> ah, good
[10:01 pm] <bz> well, that URIs were immutable, then
[10:02 pm] <bz> I thought we were gonna do that for http sometime
[10:02 pm] <bz> flip the bit
[10:02 pm] * brahmana decides not to ask such questions to be compliant with bz's wishes..
[10:02 pm] <bz> (and see what breaks)
[10:02 pm] <biesi> oh we aren't? that sucks :/
[10:02 pm] <bz> well
[10:02 pm] <bz> we're not _yet_
[10:02 pm] <bz> I also wish URIs were immutable by default instead of the nsIMutable mess..
[10:02 pm] <bz> but then again, I could use a pony too
[10:02 pm] <bz> Or better yet, a kayak
[10:02 pm] <bz> it is?
[10:03 pm] * bz looks in his "to check in" folder
[10:03 pm] <biesi> there's so much stuff that I'd like to change if I could...
Friday, March 14, 2008
Styling Chatzilla userlist and XUL Trees
In my previous post I mentioned how I was fiddling with Chatzilla "css" files to get a custom style so that and failed utterly with the userlist. And it was later I found this website: How to style your Chatzilla userlist to fit with a dark motif. - Just Imagine... a weblog
This webpage (yet another blog post) tells how the userlist can be customized. Since the userlist is a "XUL Tree" styling it is a little complicated. In XUL trees are something like dynamically populated UI components. So you do not actually know what a treecell will contain when being displayed. So we use css with a few predefined pseudo classes and a couple of properties to decide what style has to be applied for anything contained in a treecell or for that matter the whole tree itself that is present as the userlist.
This styling thing is really cool and fun. Just try it out.
This webpage (yet another blog post) tells how the userlist can be customized. Since the userlist is a "XUL Tree" styling it is a little complicated. In XUL trees are something like dynamically populated UI components. So you do not actually know what a treecell will contain when being displayed. So we use css with a few predefined pseudo classes and a couple of properties to decide what style has to be applied for anything contained in a treecell or for that matter the whole tree itself that is present as the userlist.
This styling thing is really cool and fun. Just try it out.
Saturday, May 12, 2007
Using IRC : The one place for answers to all questions
Encyclopedia is said to contain answers to almost all the questions, but many people are unaware of another place which is hell lot faster and much more lively than any encyclopedia. You find answer to almost any damn thing under the sky. Your doubts are cleared. You are not only given answers but also tools to find answers yourself and also techniques to learn and create such tools(only if you are proven worthy of it - which is really not a big thing).
This is Internet Relay Chat, better known as IRC.
You can use IRC through various networks hosted on few servers each having many channels. But few are as described above and those are networks dedicated for technical discussions and this post is about using such networks.
The very purpose of writing this post is the lack of knowledge of IRC amongst the majority of students in my engineering college. Students here can't get answers for their questions when the doubts arise, because of which the search for the solution is postponed and postponed things never actually happen. The doubt remains a doubt forever.
Apart from this, the exposure to Open source is very very bad. And in my opinion IRC would fill in this gap. So here are the details of using IRC (and a few tips).
A known analogy to understand what IRC is.
IRC is something similar to Yahoo Chat.
For using Y! chat you log on to the Yahoo server using a client, which is the Y! messenger. In a similar way for using IRC chat you need to log on to an IRC server using a client. But unlike Y! here you have a lot of clients available and you can choose(the open source power) any client that you want. Here is something that can help you.
Your Y! email-id is your identity on Y! chat. And here it will be your nickname. You will be noticed based on your nickname. So you choose a good one and maintain that same nick.
Just like you register the first time you login for Y! chat you got to register your nick. Its much simpler here. No form filling and such redundant stuff. Unless somebody has already picked up your nick you can start off using it right away. As it is obvious you will get a password which you will provide for further logins.
Once you login in Y! you would probably choose a chat room. Analogous to these chat rooms we have channels here. As you have channels like Hobbies, Romance, TeenChat we have channels like #C, #kernel, #slackware and many many more. There are channels for almost all of the open source stuff. You can choose any of the channels. You can be in multiple channels simultaneously. Channel discipline is very important. You discuss only C in #C, not even C++.
Once you are in a channel you will see the list of people who are in that channel just like you see the list of people in a chat room. Different clients provide this in different ways. Certain GUI based clients have a separate tab where as console based clients expect you to use a command to give you that list.
You can now start interacting with the people in the channel. Ask your questions and if it is a proper one and people there know the answers you will get instantaneous replies. You can have private chats also but that is not really encouraged as many others will lose the conversation that you will have. It might have been useful to someone else also and may be if there were errors a better person would have corrected you. (Its Open source.. remember that)
Thats for the analogy. Now about how to actually do all this.
1) Selecting a client.
The link above presents you with several clients. I would suggest these.
For Linux
Irssi - A console(text only) based client. It really does its job very well.
Kopete - The default KDE multi-protocol communication client. Its beautiful.
GAIM - A GUI client. For those who can't take their hands off of the mouse.
X-Chat- Ok to use.
For Windows
HydraIRC - A real good open source client. Has many features.
Cross-Platform
ChatZilla - A firefox extension. Its really cool man. The notifications are the best part of this one. This would be the best option unless you are command line freak, in which case you can use Irssi.
Download and install any one of these clients and run it.
2)Selecting a Network
As I said the developers (or the Gurus) are distributed across few useful ones amongst the several networks. Here they are.
Freenode - irc.freenode.net - The most comprehensive server. Encompasses almost everything.
Moznet - irc.mozilla.org - The mozilla developers network. One of the best place for web related stuff.
GimpNet - irc.gimp.org - As it says, for gimp related discussions.
To connect to any of these servers use this command
Port no is generally 6667.
In IRC a statement starting with "/" is considered as a command.
So to join freenode network you would do this:
Initially you will not have a password so leave that and the nickname field empty. Your username will be taken up as your nickname. You can change that later. You will get a notification when you are connected and logged on.
On GUI based servers you can use the buttons and menus to connect. Like in HydraIRC you can press Ctrl+S to bring up a dialog to select server and enter your nick and password.
3) Registering your nickname
To register your nickname you have to contact a bot called NickServ (Nickname Server).
You can change your nick using the "nick" command.
For further logins you don't have to register, you just need to IDENTIFY yourself.
4) Joining a channel
To join a channel use this "join" command
Every channel name starts with a '#'. So to join the C channel on the freenode server that you just logged on to you would do this.
There you are. You can start chatting or rather interacting.
Certain Tips:
1) Use English and proper English.
2) No slang or SMS type language.
3) Always google out your queries before asking it at IRC. They will help you only if you show to them you have indeed done some work. No spoon feeding.
4) Two most common abbreviations
--- STFW - Search the F*****g Web -- Means google it out.
--- RTFM - Read the F*****g Manual -- Read the man pages or related documentation.
When these are told, they really mean them. So watch out for these.
Thats it. Just go in and have fun.
This is Internet Relay Chat, better known as IRC.
You can use IRC through various networks hosted on few servers each having many channels. But few are as described above and those are networks dedicated for technical discussions and this post is about using such networks.
The very purpose of writing this post is the lack of knowledge of IRC amongst the majority of students in my engineering college. Students here can't get answers for their questions when the doubts arise, because of which the search for the solution is postponed and postponed things never actually happen. The doubt remains a doubt forever.
Apart from this, the exposure to Open source is very very bad. And in my opinion IRC would fill in this gap. So here are the details of using IRC (and a few tips).
A known analogy to understand what IRC is.
IRC is something similar to Yahoo Chat.
For using Y! chat you log on to the Yahoo server using a client, which is the Y! messenger. In a similar way for using IRC chat you need to log on to an IRC server using a client. But unlike Y! here you have a lot of clients available and you can choose(the open source power) any client that you want. Here is something that can help you.
Your Y! email-id is your identity on Y! chat. And here it will be your nickname. You will be noticed based on your nickname. So you choose a good one and maintain that same nick.
Just like you register the first time you login for Y! chat you got to register your nick. Its much simpler here. No form filling and such redundant stuff. Unless somebody has already picked up your nick you can start off using it right away. As it is obvious you will get a password which you will provide for further logins.
Once you login in Y! you would probably choose a chat room. Analogous to these chat rooms we have channels here. As you have channels like Hobbies, Romance, TeenChat we have channels like #C, #kernel, #slackware and many many more. There are channels for almost all of the open source stuff. You can choose any of the channels. You can be in multiple channels simultaneously. Channel discipline is very important. You discuss only C in #C, not even C++.
Once you are in a channel you will see the list of people who are in that channel just like you see the list of people in a chat room. Different clients provide this in different ways. Certain GUI based clients have a separate tab where as console based clients expect you to use a command to give you that list.
You can now start interacting with the people in the channel. Ask your questions and if it is a proper one and people there know the answers you will get instantaneous replies. You can have private chats also but that is not really encouraged as many others will lose the conversation that you will have. It might have been useful to someone else also and may be if there were errors a better person would have corrected you. (Its Open source.. remember that)
Thats for the analogy. Now about how to actually do all this.
1) Selecting a client.
The link above presents you with several clients. I would suggest these.
For Linux
Irssi - A console(text only) based client. It really does its job very well.
Kopete - The default KDE multi-protocol communication client. Its beautiful.
GAIM - A GUI client. For those who can't take their hands off of the mouse.
X-Chat- Ok to use.
For Windows
HydraIRC - A real good open source client. Has many features.
Cross-Platform
ChatZilla - A firefox extension. Its really cool man. The notifications are the best part of this one. This would be the best option unless you are command line freak, in which case you can use Irssi.
Download and install any one of these clients and run it.
2)Selecting a Network
As I said the developers (or the Gurus) are distributed across few useful ones amongst the several networks. Here they are.
Freenode - irc.freenode.net - The most comprehensive server. Encompasses almost everything.
Moznet - irc.mozilla.org - The mozilla developers network. One of the best place for web related stuff.
GimpNet - irc.gimp.org - As it says, for gimp related discussions.
To connect to any of these servers use this command
/server server name [port no [password nickname]]
Port no is generally 6667.
In IRC a statement starting with "/" is considered as a command.
DO NOT LOG ON TO IRC AS ROOT USER OR ADMINISTRATOR(in case of windows). USE A SUBSIDIARY ACCOUNT
So to join freenode network you would do this:
/connect irc.freenode.net 6667 password nickname
Initially you will not have a password so leave that and the nickname field empty. Your username will be taken up as your nickname. You can change that later. You will get a notification when you are connected and logged on.
On GUI based servers you can use the buttons and menus to connect. Like in HydraIRC you can press Ctrl+S to bring up a dialog to select server and enter your nick and password.
3) Registering your nickname
To register your nickname you have to contact a bot called NickServ (Nickname Server).
/msg NickServ HELP REGISTERwould tell you how to register.
You can change your nick using the "nick" command.
/nick new nick
For further logins you don't have to register, you just need to IDENTIFY yourself.
/msg NickServ HELP IDENTIFYwould tell you how to do that.
4) Joining a channel
To join a channel use this "join" command
/join #channel name
Every channel name starts with a '#'. So to join the C channel on the freenode server that you just logged on to you would do this.
/join ##c
There you are. You can start chatting or rather interacting.
Certain Tips:
1) Use English and proper English.
2) No slang or SMS type language.
3) Always google out your queries before asking it at IRC. They will help you only if you show to them you have indeed done some work. No spoon feeding.
4) Two most common abbreviations
--- STFW - Search the F*****g Web -- Means google it out.
--- RTFM - Read the F*****g Manual -- Read the man pages or related documentation.
When these are told, they really mean them. So watch out for these.
Thats it. Just go in and have fun.
Subscribe to:
Posts (Atom)