Its been some time since I have worked on Jira. Creating plugins and modifying Java/Velocity Template/jsp code was what I used to do earlier. It was fun earlier when you start of learning new things and understand the structure of the excellent code written for Jira. But then the work becomes monotonous and you feel that you have more to give. After having finished with Enthiosys but developing some high end stuff based on SVG, javascript and HTML, I was asked to do some work on Jira.
The idea is a simple one. try to build something that would let users chat about some Jira issue and then log the chat into the Jira issue as comments. :) . Simple as it sounds, I had to set up a Jabber server. I used the excellent OpenFire as the server. The LDAP credentials for the company, I managed to obtain and then configured it so that all the users of the company could log in. Jira 3.13.4 was downloaded and I managed to connect to LDAP as well with the help of Indraneel.
Then came the difficult part. The application which was to be in AIR. I first thought to try to build it using flash. Actionscripting is something that I could do. But to have frames build movie clips is something that I could not do. I was good with HTML and Javascript and thought I would do it my way using HTML Ajax. I decided to build the required files to communicate with Jira and Jabber in flash so that I could use them in HTML using the window.runtime object provided by Adobe AIR.
Jira offers 2 ways of external communication. SOAP and XML RPC. I downloaded a bunch of those classes which facilitated the SOAP communication, because SOAP was well documented and XML RPC was crude, but did not have much luck getting information from Jira. The envelope and the structure of the xml was not being detected by the class for some reason. I had success with XML RPC and decided to go on with that.
The communication with Jabber was done with the excellent XIFF library. It is one of the best libraries that I have seen but is a little less in documentation. That is ok as long as it has all the necessary stuff required to develop.
I tried compiling the libraries into swf files, but for some reason they were not included in the file. I had just used an import statement. Ashish suggested to use a function and after using a function which initiated the class, I managed to get all the libraries for access. Event listeners were something that needed to be taken care of. At first the idea was to call Javascript from the Actionscript but the sand box had restrictions. This made me create event handlers in javascript and attach then using javascript. That worked fine.
With all the things setup, the next step was to build the interface. The interface would be simple with a list of contacts, an option to search, find and add contacts and chat with a contact. To create a native window with the chat was the next big step. I managed to populate the list of contacts with online and offline contacts (this list would change as and when the user logs in).
The native window creation according to the chat was tricky. It was tricky because to show the window was not a big deal, but to load chats in it was a pretty big deal. The handle for the window must be maitained by the main window and the chats must be sent as well. As of now I am working on this and I hope Ill make progress.
Showing posts with label air. Show all posts
Showing posts with label air. Show all posts
Saturday, May 16, 2009
Wednesday, June 11, 2008
Reactions
The post has a peculiar title because I had a quite heart warming one when I went through the Workstreamer blog. Theres a post titled 'What Does Your Workspace Say About You?' and that just jots down a instance where a desktop uses the Workstreamer client. It feels so much refreshing when something that you have done goes out in the open. The whole stuff was created from scratch and I also had the help of the twitter client snitter (code). The Open APIs where also designed and with the help of my dear friends Abhilash, Rohan and Abhijat.
I also found that Workstreamer had a community in Facebook. There are pictures with me in it too. Extreme right here.
Nice to be part of a great team. KUDOS !!!
I also found that Workstreamer had a community in Facebook. There are pictures with me in it too. Extreme right here.
Nice to be part of a great team. KUDOS !!!
Tuesday, April 22, 2008
AIR again
In a previous post of mine I had briefly jotted down what I liked about AIR and how it all came together for Workstreamr. This time around I would like to write about some of the problems I had to face when coding in HTML , Javascript, CSS (AIR application) and how I managed to find a way about those problems. I would especially like to thank Snitter for developing a great product in HTML/Javascript/CSS so that learners like me could evaluate and understand the product.
I initial idea was the same as any other Open API system. Access data using certain credentials via http, parse and interpret the data, format the data and then display the data. So my primary concern was to separate the modal/controller/view layers that come into picture. The javascript files were written using the prototype library and the effects (even though little) were done using scriptaculous. After defining the stuff that I wanted, I went on to make managers (like sound manager) and providers (like htmlcreator which gave me the html designed code when I gave a json). The main application was the launch pad for all the other Javascript classes.
The application required a modal window and an accordion. The Modal Window was created with Controls.Modal in mind but I simplified it a bit. The Accordion was inspired by accordion.js found in scriptaculous. The Modal window had problems loading the first time as AIR had issues attaching/running events after the window is opened. So what ever code you are going to write you better initialize it first. eg - The eval execution is limited in the Sandbox Application and Prototype uses evalScripts for all insert statements.
The posts that I displayed had links in them with hrefs. Now if I had left them as it were, as soon as a user clicked them, they would open in the same window as the application. To open links in you default browser window you will have to use
As the eval function accessibility is limited the passing of a string to settimeout/setinterval is also not allowed. The way around is to actually pass a function/function name to this
I also juggled around naming divs in such a fashion that it becomes easy to get details in a certain fashion. Say I needed a user id when I clicked a checkbox. This generated checkbox could be given an id something like 'user_22_message_3242', so that parsing/splitting it and finding out the user id was a piece of cake. I cannot think of a better way than this. :)
Icon tray setting up was also a great feature that AIR offers. But be careful when you aim for the MAC as well. A specific check is required to see if there is dockicon support else when you minimize the window, the whole application may disappear.
The other thing which gave me some problems was the notification system (Growl). Now AIR does not support this but we make the application have this by using certain actionscripts. I looked through the actionscripts that Twhirl and Snitter uses. You could write your own script if you want the customization. We will have to tell AIR to add this in the path as well by doing a script include
The theme manager was another thing that I loved doing. As of now the theme manager loads a predefined xml file with all the theme details in them and on changing the selected item in the list displayed, it changes the CSS file which dynamically loads the theme. The images are also maintained in this theme folder so that a uniformity is obtained. The sound implementation was pretty easy. It only plays mp3 files(as I understand) but thats ok.
The development time required for an AIR application with HTML, Javascript and CSS is quite rapid. This client was developed within 1.5 months (I had other work as well). It has a great platform support (even linux now!!) and I expect a lot of verified AIR Applications to come up pretty rapidly.
I initial idea was the same as any other Open API system. Access data using certain credentials via http, parse and interpret the data, format the data and then display the data. So my primary concern was to separate the modal/controller/view layers that come into picture. The javascript files were written using the prototype library and the effects (even though little) were done using scriptaculous. After defining the stuff that I wanted, I went on to make managers (like sound manager) and providers (like htmlcreator which gave me the html designed code when I gave a json). The main application was the launch pad for all the other Javascript classes.
The application required a modal window and an accordion. The Modal Window was created with Controls.Modal in mind but I simplified it a bit. The Accordion was inspired by accordion.js found in scriptaculous. The Modal window had problems loading the first time as AIR had issues attaching/running events after the window is opened. So what ever code you are going to write you better initialize it first. eg - The eval execution is limited in the Sandbox Application and Prototype uses evalScripts for all insert statements.
The posts that I displayed had links in them with hrefs. Now if I had left them as it were, as soon as a user clicked them, they would open in the same window as the application. To open links in you default browser window you will have to use
air.navigateToURL(new air.URLRequest('http://google.com'));Sanctifying this was necessary as we did not want them to load in the same window. Adding an onclick event to the got post/message wont do any good here as the evalScripts will not be executed after the prototype insert statement. Snitter does a work around this by attaching an event listener for the whole area where the message displays. Checks whether its a link type, if yes issues this command. The problem that I faced still was even though I returned false from that method, the link open in the same window. The change that I did was that I took the href attribute value and put it in the alt attribute and cleaned up the href attribute value.
As the eval function accessibility is limited the passing of a string to settimeout/setinterval is also not allowed. The way around is to actually pass a function/function name to this
polling = setInterval(function(){alert('getting');},timeout);There were also CSS based minor issues. As you see in most of the twitter clients, when the user hovers over the avatar, he sees a envelope which he uses to send a direct message. I thought of doing it the JS way but then some clever CSS caught my eye. If you consider the image to be in a div and the sub envelope image to be in a child div then the CSS would be like
.child {visibility:hidden;}which I think is brilliant.
.parent:hover .child{ visibility:visible;}
I also juggled around naming divs in such a fashion that it becomes easy to get details in a certain fashion. Say I needed a user id when I clicked a checkbox. This generated checkbox could be given an id something like 'user_22_message_3242', so that parsing/splitting it and finding out the user id was a piece of cake. I cannot think of a better way than this. :)
Icon tray setting up was also a great feature that AIR offers. But be careful when you aim for the MAC as well. A specific check is required to see if there is dockicon support else when you minimize the window, the whole application may disappear.
nativeWindow.minimize();Always do an ordertofront after you restore the main window. This will make the application better and sane.
if(!air.NativeApplication.nativeApplication.supportsDockIcon) { // Fix for Mac
nativeWindow.visible = false;
}
The other thing which gave me some problems was the notification system (Growl). Now AIR does not support this but we make the application have this by using certain actionscripts. I looked through the actionscripts that Twhirl and Snitter uses. You could write your own script if you want the customization. We will have to tell AIR to add this in the path as well by doing a script include
<script type="application/x-shockwave-flash" src="notification.swf">I wanted a clean interface without those Adobe AIR based controls so I went for the transparent -true, chrome- none and visible -true configuration in the main file. This also requires that you have the close control (as in a image which calls the close routine).
</script>
The theme manager was another thing that I loved doing. As of now the theme manager loads a predefined xml file with all the theme details in them and on changing the selected item in the list displayed, it changes the CSS file which dynamically loads the theme. The images are also maintained in this theme folder so that a uniformity is obtained. The sound implementation was pretty easy. It only plays mp3 files(as I understand) but thats ok.
The development time required for an AIR application with HTML, Javascript and CSS is quite rapid. This client was developed within 1.5 months (I had other work as well). It has a great platform support (even linux now!!) and I expect a lot of verified AIR Applications to come up pretty rapidly.
Friday, April 11, 2008
Mixed Ideas
The Workstreamr team had a party yesterday. Geoffreys was the venue. Ben was the host and we reached a bit late after the delayed travel. The party had already started when we had reached there and we started out with a Corona each. Abhijat was fasting and did not have any alcohol. Amol joined us later when we ordered a Long Island Ice Tea. Little did I know that this one was going to be one nasty drink. As I understand from Abhilash, it was a mix of Gin, Vodka and White Rum. One nasty combination. I was half way through the drink when I asked Amol about the complexities that were involved in getting into the Product Usability and Design Group.
I consider that every individual involved in a project/class bring a unique set of ideas to the table. Some give more and are able to imagine a situation fast. I consider myself to be artistically efficient. I like to work on Photoshop and Gimp is my favorite. The Workstreamr Client which is in Adobe AIR uses Html, CSS and javascript, was done with some sense of what a typical client would look like. The available clients were also taken into consideration along with great IM clients such as Gtalk and Open Source Gaim ( I am not that into Yahoo! coz it cramps my system sometimes). And I think I did a pretty good job at it.
The point here that I express is how much effectiveness can I as an individual can provide if I were to be in a position designing the usability. programming concepts come into picture here and as per Amol, Web 2.0 applications design often requires this kind of a background. If you are able to visualize a product taking into consideration all its complexities, both technical and usability, then you could shine anywhere. That is what I try to communicate. To think like a normal user, a majorly dumb one, is a main ingredient. That lets you conceptualize more I believe. It is sure that I would not let go of programming. Ten years down the lane I still see myself as coding. But I also would like to explore the designing area, just to get a feel of it. Not taking in too much responsibilities but expressing my ideas so that the end product would gain.
To have an idea is normal but to struggle for the idea makes the thought worth while.
I consider that every individual involved in a project/class bring a unique set of ideas to the table. Some give more and are able to imagine a situation fast. I consider myself to be artistically efficient. I like to work on Photoshop and Gimp is my favorite. The Workstreamr Client which is in Adobe AIR uses Html, CSS and javascript, was done with some sense of what a typical client would look like. The available clients were also taken into consideration along with great IM clients such as Gtalk and Open Source Gaim ( I am not that into Yahoo! coz it cramps my system sometimes). And I think I did a pretty good job at it.
The point here that I express is how much effectiveness can I as an individual can provide if I were to be in a position designing the usability. programming concepts come into picture here and as per Amol, Web 2.0 applications design often requires this kind of a background. If you are able to visualize a product taking into consideration all its complexities, both technical and usability, then you could shine anywhere. That is what I try to communicate. To think like a normal user, a majorly dumb one, is a main ingredient. That lets you conceptualize more I believe. It is sure that I would not let go of programming. Ten years down the lane I still see myself as coding. But I also would like to explore the designing area, just to get a feel of it. Not taking in too much responsibilities but expressing my ideas so that the end product would gain.
To have an idea is normal but to struggle for the idea makes the thought worth while.
Thursday, March 27, 2008
AIR for the mind
These days its a steep learning curve of me. I have been fiddling around with Adobe AIR for some time now and I'll say every second of it has been great. Manish has been insisting that I document the things I have done. But I find it better to do than to document. Of course in that case what you know is bottled and not useful to others. I'll try to jot down the stuff (though very little) that I understand after 3 weeks of AIR.
The reason why I looked at Adobe AIR was for Workstreamr. The first thing that I found was documentation provided by Adobe. These livedocs were extremely helpful. I installed the runtime environment from Adobe and then the sdk. Before looking at the sdk I saw an Eclipse based IDE called Flex Builder provided by Adobe. I downloaded this and started my work on this.
There are 3 ways you could make an Adobe AIR app. Using HTML/Javascript, Flex or Flash. I was always interested in Actionscript and thats why I tried out Flex Developer. Here it is required that you write xml file which will be converted into Actionscripts (swf files at last) and will be run by AIR. The xml file creation for this was greatly simplified by Flex builder but I had to learn some Actionscript within a short frame of time. I fiddled wit hthis for some time after which I decided to go and check out the HTML/Javascript based approach. Aptana was used here as it had a great support for building AIR apps.
It took me less time to get used to all the nifty stuff that AIR had provided to make the HTML based approach work. The base is just an Html file which includes a main Javascript file called AIRAliases. It contains all the aliases that you need to access the Runtime Environment. The AIRIntrospector Javascript file is another thing that is required for debugging purposes. When the app is running press F11 and you will see the Introspector pop up.
Now comes the UI based stuff. I loved what Snitter, Twhirl, Spaz and Pownce had done with their AIR applications. The shadows and stuff. In Flex this was easy. Just create a shadow object and give that to the main window. For the Html part this was done making use of a semi transparent image ( dot fading out ) being repeated through out a div with a large border. I had done most of my work using the prototype and scriptaculous libraries, so I chose them as the main Javascript libraries for the AIR app too. The other options include EXT, Jquery, Spry, MochiKit etc.
The documentation for the various methods that AIR has was taken as a reference. Some of the stuff like Effect queuing did not work for me using Scriptaculous. I am also told that JQuery is the most used library for the HTML based development. I'll probably shift to JQuery once I get a feel of it. [:)] .
The notifications is another thing that I was trying to do. Those small notifications that come up on the right bottom of your screen when ever someone messages you. It took me sometime to find out that this 'purr' was indeed an Actionscript that is included with the main Html file in snitter as well as Spaz. I decompiled this swf file ( sorry but I had to) and looked inside the code, managed to find the notifier, the notifier queue and the actual 'purr'. The color theme must be changed, so Ill have to hack the whole code (I think).
The Javascript that is made has been done with Object Orientation in mind. The Html / Javascript and CSS are decoupled. Another aspect I like about doing this in Html is that a single change of CSS changed the UI completely. Talk of decoupled UI and Functionality.
Still working on this and hope it will end good. I would like to thank all these apps made in Adobe AIR which I took as reference (both the Html ones and the Swf ones I managed to hack).
The reason why I looked at Adobe AIR was for Workstreamr. The first thing that I found was documentation provided by Adobe. These livedocs were extremely helpful. I installed the runtime environment from Adobe and then the sdk. Before looking at the sdk I saw an Eclipse based IDE called Flex Builder provided by Adobe. I downloaded this and started my work on this.
There are 3 ways you could make an Adobe AIR app. Using HTML/Javascript, Flex or Flash. I was always interested in Actionscript and thats why I tried out Flex Developer. Here it is required that you write xml file which will be converted into Actionscripts (swf files at last) and will be run by AIR. The xml file creation for this was greatly simplified by Flex builder but I had to learn some Actionscript within a short frame of time. I fiddled wit hthis for some time after which I decided to go and check out the HTML/Javascript based approach. Aptana was used here as it had a great support for building AIR apps.
It took me less time to get used to all the nifty stuff that AIR had provided to make the HTML based approach work. The base is just an Html file which includes a main Javascript file called AIRAliases. It contains all the aliases that you need to access the Runtime Environment. The AIRIntrospector Javascript file is another thing that is required for debugging purposes. When the app is running press F11 and you will see the Introspector pop up.
Now comes the UI based stuff. I loved what Snitter, Twhirl, Spaz and Pownce had done with their AIR applications. The shadows and stuff. In Flex this was easy. Just create a shadow object and give that to the main window. For the Html part this was done making use of a semi transparent image ( dot fading out ) being repeated through out a div with a large border. I had done most of my work using the prototype and scriptaculous libraries, so I chose them as the main Javascript libraries for the AIR app too. The other options include EXT, Jquery, Spry, MochiKit etc.
The documentation for the various methods that AIR has was taken as a reference. Some of the stuff like Effect queuing did not work for me using Scriptaculous. I am also told that JQuery is the most used library for the HTML based development. I'll probably shift to JQuery once I get a feel of it. [:)] .
The notifications is another thing that I was trying to do. Those small notifications that come up on the right bottom of your screen when ever someone messages you. It took me sometime to find out that this 'purr' was indeed an Actionscript that is included with the main Html file in snitter as well as Spaz. I decompiled this swf file ( sorry but I had to) and looked inside the code, managed to find the notifier, the notifier queue and the actual 'purr'. The color theme must be changed, so Ill have to hack the whole code (I think).
The Javascript that is made has been done with Object Orientation in mind. The Html / Javascript and CSS are decoupled. Another aspect I like about doing this in Html is that a single change of CSS changed the UI completely. Talk of decoupled UI and Functionality.
Still working on this and hope it will end good. I would like to thank all these apps made in Adobe AIR which I took as reference (both the Html ones and the Swf ones I managed to hack).
Tuesday, March 25, 2008
Workstreamflow
This one is all about the perspective changing project that I am currently a part of. Workstreamr .The work done in this application has been tremendous. Though I am not in the development team for this project, I have done tit bits for it and I feel I have accomplished more than I ever thought of accomplishing.
The project is an entire shift of the thought process that a normal person undergoes. The original idea conceivers, Stowe, Ben and Sam, had a great thought in mind. To give the users the power to manage , maintain and view data. A truly Open Source oriented concept with Web 2.0 backup. The data has been categorized into groups so that the users could distinguish and relate. The data flows as streams of information and the user has the power to choose to view, respond or ignore.
The feature that I find very intriguing is 'the handing over the power to the user'. Many applications that is web oriented don' do that. They have a fixed way of doing things and the users are happy with it. This lets the users be dumb (like those early days of internet). A wiki based structure with collaboration and information passing is the core 'funda' of this application.
Time based. This is a great shift in perception. The information you see is time based. It shows up taking into consideration the time factor.. It does not have a state maintained. 'Backtracking becomes tricky here and tedious' is a statement that would come into ones mind after this. Versioning is a great system that is used by many Web2.0 based systems to handle this. The change triggers a version which could be backtracked and changes reviewed. The Configuration Management Systems work in this fashion and they work perfectly fine.
Extensibility is another thing I like. How could you be happy with a product which you can't play around with ? (emm ... Windows ? ) . And all platforms are not like the OS-X anyway ! This application lets you fool around with it. I guess the users will love that.
Grouping of data has been a core factor of all databases. Think of a world where you cant correlate or group data. You can't bundle stuff together. That makes a very unrelated series of events which is useless and odd. This grouping is another characteristic that makes this application stand apart from any other one.
Filters. Again a database oriented concept but a general computer science one. Why would I see unwanted information again ? I would rather see filtered information than see all information, even irrelevant ones. If I have a filter already , it is very likely that I will use it again. So I'll store the filter and share them (Web 2.0 comes in again) so that other people with similar tastes could use it.
User management is a main ingredient in any project management system. Assigning, Owning, Tracking Progress are all factors that a Manager would like to do in his Project Management Tool. Versioning also comes into picture here as the application is intended to be stateless.
The Open API is the last thing I would like to write about. In the modern world, a high end graphically excellent functionally proficient web application is doomed if it does not expose a public api for the users to fiddle with. This a part of passing the power on to the user. Workstreamr has this factor in mind and exposes an API which is simple to use. A client will also be created in Adobe AIR ( and that where I come in ) which will let the users request and respond to their data which comes as streams of information.
The first cut will be out in some time but until then it all wait and watch.
The project is an entire shift of the thought process that a normal person undergoes. The original idea conceivers, Stowe, Ben and Sam, had a great thought in mind. To give the users the power to manage , maintain and view data. A truly Open Source oriented concept with Web 2.0 backup. The data has been categorized into groups so that the users could distinguish and relate. The data flows as streams of information and the user has the power to choose to view, respond or ignore.
The feature that I find very intriguing is 'the handing over the power to the user'. Many applications that is web oriented don' do that. They have a fixed way of doing things and the users are happy with it. This lets the users be dumb (like those early days of internet). A wiki based structure with collaboration and information passing is the core 'funda' of this application.
Time based. This is a great shift in perception. The information you see is time based. It shows up taking into consideration the time factor.. It does not have a state maintained. 'Backtracking becomes tricky here and tedious' is a statement that would come into ones mind after this. Versioning is a great system that is used by many Web2.0 based systems to handle this. The change triggers a version which could be backtracked and changes reviewed. The Configuration Management Systems work in this fashion and they work perfectly fine.
Extensibility is another thing I like. How could you be happy with a product which you can't play around with ? (emm ... Windows ? ) . And all platforms are not like the OS-X anyway ! This application lets you fool around with it. I guess the users will love that.
Grouping of data has been a core factor of all databases. Think of a world where you cant correlate or group data. You can't bundle stuff together. That makes a very unrelated series of events which is useless and odd. This grouping is another characteristic that makes this application stand apart from any other one.
Filters. Again a database oriented concept but a general computer science one. Why would I see unwanted information again ? I would rather see filtered information than see all information, even irrelevant ones. If I have a filter already , it is very likely that I will use it again. So I'll store the filter and share them (Web 2.0 comes in again) so that other people with similar tastes could use it.
User management is a main ingredient in any project management system. Assigning, Owning, Tracking Progress are all factors that a Manager would like to do in his Project Management Tool. Versioning also comes into picture here as the application is intended to be stateless.
The Open API is the last thing I would like to write about. In the modern world, a high end graphically excellent functionally proficient web application is doomed if it does not expose a public api for the users to fiddle with. This a part of passing the power on to the user. Workstreamr has this factor in mind and exposes an API which is simple to use. A client will also be created in Adobe AIR ( and that where I come in ) which will let the users request and respond to their data which comes as streams of information.
The first cut will be out in some time but until then it all wait and watch.
Tuesday, March 4, 2008
Alternate Comet Ruby On Rails
I happened to have a talk about the previous post to Raja. The implementation had its own problems and changes.
Firstly : The Service Layer of the app, the part which communicates with the queue, must be separated from the controller. We don't want the controller to have a heavy load. The service layer will not know the part of the application that communicates with it and the controller will not know who its contacts. This ensures that even if the service layer has implementation changes, it will not affect the controller thus making it entirely a different entity. I guess this kind of distinction will only come with age and experience. The Facade Pattern is the base.
Secondly: The application is better off with cache implementations. Mainly because the queues are designed to serve a purpose. Communication between apps. The Cache will also be maintained by a service layer and the access via the controller will either be fetched from the cache or if expired from the database. To have a uniformity between the kind of platforms accessing the application (say Adobe AIR and the browser accessing the Mongrel server), we could have an identifying parameter parameter passed along with the url which tells the controller the type of client and the resultant format of output (say XML/ JSON/RHTML).
I feel I have lifted myself a step now !! Thanks Raja .
Firstly : The Service Layer of the app, the part which communicates with the queue, must be separated from the controller. We don't want the controller to have a heavy load. The service layer will not know the part of the application that communicates with it and the controller will not know who its contacts. This ensures that even if the service layer has implementation changes, it will not affect the controller thus making it entirely a different entity. I guess this kind of distinction will only come with age and experience. The Facade Pattern is the base.
Secondly: The application is better off with cache implementations. Mainly because the queues are designed to serve a purpose. Communication between apps. The Cache will also be maintained by a service layer and the access via the controller will either be fetched from the cache or if expired from the database. To have a uniformity between the kind of platforms accessing the application (say Adobe AIR and the browser accessing the Mongrel server), we could have an identifying parameter parameter passed along with the url which tells the controller the type of client and the resultant format of output (say XML/ JSON/RHTML).
I feel I have lifted myself a step now !! Thanks Raja .
Monday, March 3, 2008
Comet Ruby On Rails
The stuff that we do in the company is quite cool. It lets me, personally, to go through many technologies and implement many ideas. Concepts in theory is not great unless you start to implement those. A new thing that we are trying to accomplish is the functionality that a Comet Server gives, an HTTP push. This must be implemented in Ruby On Rails. Now the point here is that as HTTP is a connectionless protocol, we cannot pass stuff from the server to the client (unless the client requests). To have this functionality, we must either do a polling technique, where in the client constantly accesses the server for information or a live connection (may be a flash connection). Now another techniques which goes against this HTTP connectionless concept is the one that Comet deals with. A long lasting HTTP connection, either streaming or long.
Juggernaut is a Ruby On Rails plug-in which has this kind of functionality. It uses a flash open socket connection to get this server side push. Now this is great but the main problem that I felt is the firewall problem. Most of the firewalls do allows connections from other ports to go through them. Juggernaut also say that we could connect through the 443 port (http ssl) and that would solve the firewall issue. For a general need this is great.
My requirement was a little specific and I needed more stuff to get this stuff working. That was when I got to see the Active Messaging plug-in that Ruby On Rails had. A plug-in which could take in data from an Event Driven Architecture based product (say Queue / Messaging) and consume results in a Provider/ Subscriber model. The application also needed a lot of database optimization ( it will have to survive a lot of select statements). So an intermediated queue is perfect.
This is what it might look like.
The only problem that I am facing is that by default the Active MQ is supposed to be a first Come First Serve queue. Now this does not serve my purpose as there might be many clients subscribing to the out queue. What I need is durable subscribers and that problem has been addressed in their thread.
This is a great way of accessing data (messages) as it is inherently the publisher/subscriber pattern (which I need) and the interoperability between different application could also be possible (a flex app accessing not HTTP information ?). Load balancing could also be done on queues !!
Juggernaut is a Ruby On Rails plug-in which has this kind of functionality. It uses a flash open socket connection to get this server side push. Now this is great but the main problem that I felt is the firewall problem. Most of the firewalls do allows connections from other ports to go through them. Juggernaut also say that we could connect through the 443 port (http ssl) and that would solve the firewall issue. For a general need this is great.
My requirement was a little specific and I needed more stuff to get this stuff working. That was when I got to see the Active Messaging plug-in that Ruby On Rails had. A plug-in which could take in data from an Event Driven Architecture based product (say Queue / Messaging) and consume results in a Provider/ Subscriber model. The application also needed a lot of database optimization ( it will have to survive a lot of select statements). So an intermediated queue is perfect.
This is what it might look like.
The only problem that I am facing is that by default the Active MQ is supposed to be a first Come First Serve queue. Now this does not serve my purpose as there might be many clients subscribing to the out queue. What I need is durable subscribers and that problem has been addressed in their thread.
This is a great way of accessing data (messages) as it is inherently the publisher/subscriber pattern (which I need) and the interoperability between different application could also be possible (a flex app accessing not HTTP information ?). Load balancing could also be done on queues !!
Subscribe to:
Posts (Atom)