Monday, August 17, 2009

Demo and packaging done

After some re-assessment of our goals for GSoC, we decided to bring out the standalone version of beacon and continue with the integration later.

I got sponsored for sysadmin-test by Fedora-infra and have set the demo up here. To access it, one needs to create an account on http://publictest3.fedoraproject.org/accounts/ and then use that test account.

Also, I finally managed to get over my packaging blues with some kind help from Rakesh Pandit and have submitted a review request here.

On the whole, this GSoC has been fun (I know the project is not finished yet, but the GSoC phase is coming to a close). This year, it was not as much about GSoC as it was about implementing a product which would be guaranteed in use by the community. I interacted with the community more than last time.

Last but not the least, a heartfelt thanks to a very cool mentor, an amazing upstream (esp. Nandeep), and a very supportive community.

Monday, July 13, 2009

Standalone DocBook editor is ready!

Finally finished the DTD for all the tags :) *phew*

Also added a document tree which helps easy navigation, addition and deletion of elements etc. Please check this feature out here. It is really cool.

Checklist: Deliverable 1 done.

For the other two deliverables,test results and documentation, I have an idea. I will write the documentation in DocBook format using Beacon itself.

Note: Since the demo is still in testing do not trust your documents with it yet. We'll make it stable soon. Better yet, it would be great if community could report bugs/suggestions. :)

Saturday, July 11, 2009

XSLs done!

Finally sent my XSLs to Nandeep for review yesterday. He must have committed it by now.
Also found a DocBook CSS which publican uses and replaced the existing one. Using the same CSS might help in integrating later on.

Will finish the DTD today.

Now off to fill the mid term evaluation form...

Tuesday, July 7, 2009

What's Next

Mid-terms evaluations are knocking on door and its been quite a wild ride coding. Web development is a different ball game altogether and I am beginning to understand why they call JavaScript the world's best worst language :D

After I have spruced the Beacon code and finally finished the DocBook DTD with the initial subset, I am going to start the next big task of getting Beacon integrated with Zikula and Publican for a seamless documentation experience.

It looks like Zikula has some text editors and a plug-in for them. I have to find the best way to get Beacon fit in that work flow. Fortunately Beacon already has a feature that allows one to embed it on any page. So it shouldn't be that difficult.

Am still looking for a best way to get Beacon integrated with Publican. It would be nice if the community can suggest a way to do it.

Thursday, July 2, 2009

DocBook Editor 2

Just completed a tiny DTD for DocBook corresponding to the small set of tags for which I had written the XSLs. I am so glad it works! (http://dev.gentooexperimental.org/~n9986/beacon/editor/ works best with firefox)

Now on it is just a matter of adding more elements to get a richer tag-set for DocBook till the mid-term evals. The basic infra is all set up (will try to keep improving usability though).

Also added a brand new and better CSS.

On the other side I think I should try and get more community involvement into developing the editor as the number of DocBook elements is *huge*.

I'll start by explaining what beacon is and how it works.

Beacon is a What you see is what you mean editor which relies heavily on XSL for XML to HTML conversions and vice-versa.

Most of the work involved in making a plugin is writing the two XSLs. One is required for converting the XML to HTML so that it can be displayed in the browser. And the other for converting the HTML back to XML. All these operations are done on the server side using PHP (or Python).

One may wonder, why rewrite XSLs if they already exists, like for Docbook for example. The reason is that Beacon needs some 'hooks' in the generated HTML so it can pick up the nodes using Javascript. This is required to do multitude of tasks like rendering inline editors, maintaining structural sanity, addition/deletion of new nodes, etc. Since HTML and Docbook XML tags are very different, there needs to be some way to map the XML tags over to HTML. These hooks are done using title attribute on tags. So for example, the tag will be rendered in HTML as:

< p title = "docbookPara"> Somethings are best with a title < /p >

Title tags tend to be most unobtrusive here and works well for DOM manipulation which is made even easier thanks to jQuery.

Once the HTML has been rendered, some Javascript magic makes it editable via inline editors of various types. We are still working on the node adding/deleting feature. Once that is done we will have a more or less a complete editor.

The validation of the generated HTML is kept in check via a Javascript based DTD.

So the user cycle of Beacon is:

new document -> XML -> HTML -> XML

All ajax-y communication is handled by JSON (except for file upload which uses an iframe of course).

Since its a web based it relies completely on Ajax for any post first page load. The UI is pretty much like a desktop Application with Tabs, sidebar etc.

To sum it up, a plugin now requires:
  1. Couple of XSLs
  2. Javascript based DTD
  3. Some trivial PHP code
  4. CSS + some template XMLs

I will write a tutorial on how to make a plugin for docbook next. Will be nice if folks chip in to get in as many tags supported as possible.

DocBook Editor 1

It's been very quiet in here. This month has been a marathon of coding and a lot of other events on the home front.

First off, a few non-GSoC related developments:
  • I finished college. (Phew!)
  • I got placed in Red Hat as an Associate Software Engineer. (gleee!)
  • I won the Sun India Code For Freedom contest for my B. Tech Project. (ZOMG!! yes that was COMPLETELY unexpected!)
  • I went out for a small trip this weekend after almost 2 years.
Now to the DocBook Editor...

I started off by learning XSLT (tough!) and making an initial RPM for Beacon and submitted it for review. I created a Feature page and worked on deciding on an initial subset with the help of the Fedora-docs list.

Here are a few links to complement the above:

https://fedoraproject.org/wiki/DocBook_Editor_Documentation
https://fedoraproject.org/wiki/Features/DocBookEditor
https://fedoraproject.org/wiki/DocBook_Editor

Then, I constructed an initial XSL by referring to the example DocBook file in the Fedora Documentation repository and based on the initial tag set that was selected after a community review.

Initially, I fixed a few bugs in Beacon to learn the source code and worked on making it more convenient to add plug-ins by changing the implementation so that beacon needs only a DTD from the plug-in makers (which is us) rather than having us code the whole Javascript. A successful implementation of this would save a lot of time in feature addition and creation of plugins.

Apart from the DTD, I was learning the tools more from implementation perspective like JavaScript and jQuery library used in Beacon.

The last week has been the most exciting. Working with Nandeep Mali, the lead Beacon dev and my point of contact for the Beacon upstream, we got the DTD feature implemented to some extent and its working like a charm. The WYSIWYM is also working and just few more additions need to be done to make this a solid XML editor.

The DTD is actually a giant Javascript object which contains details about every node and its structure (like child, parent, siblings). One may think that why not use an existing WYSIWYG editor like TinyMCE. This is not very feasible because WYSIWYG editors are notorious for
the output they produce. This is what Beacon is trying to avoid by adding a different type of editor. The user will be places with a fill-in-the-blanks type of editor so the generated XML will retain its sanity and conform to Docbook DTD. Makes it easy for the Docs team as well.

Now for the treat: http://dev.gentooexperimental.org/~n9986/beacon/editor/

The above URL is a demo of what we have been working with (I hope the Gentoo URL is not a problem. Beacon was a Gentoo SoC project and I cannot get PHP with JSON and XSLs on my fedora account).

The work till now mainly consisted of writing the XSLs for DocBook and making changes to the beacon core. One final enhancement in the usability of beacon would be a drag and drop feature that has not been committed so far as it is very slow at the moment. Once that is ready it will be very easy to add nodes at any point and still not mess up the corresponding XML.

I have been writing the DTD for DocBook since yesterday and will be able to commit it by very soon. So we can expect another blog post about it very soon.

Has been a fun journey so far. More to come in the next post.

Saturday, May 2, 2009

GSoCer again!

It feels awesome as I type this :) I am a GSoC student for Fedora this year too! I'll be working on Implementing a DocBook plug-in for Beacon. I am being mentored by Yaakov Nemoy and Karsten Wade is my technical guide! I feel honored to work with such amazing people :)

Hope the documentation team finds the editor useful.

Monday, February 23, 2009

What's been up...

Phew! back to blogger after a long time, I must say after trying so hard to get over my hesitation, I am not quite successful in getting myself into blogging.

What has been up recently is that I finally got started with my Red Hat internship. My target is to introduce java profiling in SystemTap. I have been reading the SystemTap code to find out where exactly the tokens are parsed and where is the code translated into the corresponding C code.

To an extent I have been successful thanks to the comments in the main.cxx stating which phase begins when, but I guess the use of kprobes has somewhat hidden how the token representing the probe point is mapped to the location where it is actually found (or maybe it is not and I could not find it).

Also I have found a few C based java application profilers like JMP (TIJMP for the JVMTI supporting versions of java). I am looking at their code to know how to interface with the JVM using such tools.

Looking forward to be able to accomplish the task.

On the Sarai Fellowship front I am still in the process of recording the speech samples for my speech recognition project for the OLPC. Recording speech samples and typing out the text has turned out to be a lot more time consuming and laborious than I initially anticipated (Might also be because I need to arrange my schedule according to the times when the children are available which is becoming difficult because of my classes). I am also very hopeful of getting an XO soon thanks to Sankarshan Sir, Mr. Amit and Mr. Sayamindu.

I am praying it all comes out fine.

Next, I was invited to the National Institute of Technology, Durgapur to talk to the newerbies about how to contribute to FOSS in their annual FOSS festival Mukti.in.

It was an amazing experience. I talked about the philosophy of FOSS, why should they contribute and whats in it for them. Then I moved on to what it takes to be a contributor and how to contribute. The How part was divided into two categories, for those who want to contribute code, and for those who want to contribute by other means like helping out with the artwork, documentation, translations, publicity etc. I also talked about Fedora and OLPC in slight details as I could supplement the information there by my own experience. The presentation slides can be found here.

It was nice to try and answer questions from the audience when they gave me their skill set and asked me where could they fit in. It was also heartening to see people interested in my GSoC project and asking me about system side programming and SystemTap.

Over all, I was satisfied at the end of the talk and felt it was a job well done though I was tensed about screwing up the schedule of the event by extending the talk by about an hour.