forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oshani Seneviratne" <>
Subject Re: Google Summer of Code project
Date Tue, 27 Mar 2007 16:17:57 GMT

Thanks a lot for all your comments!

I have revised my proposal [1] a bit based on your suggestions and it
is yet again open for review. Please note that I did not change some
of the things, which I have certain doubts about on implementing.
However, based on your advice I am willing to change the proposal once

As for the questions you raised, please see my comments inline.

On 3/25/07, Ross Gardler <> wrote:
> You have scheduled a whole week for "Design for plugins". Can you expand
> on exactly what you think this design will contain.

Actually, I've allocated more than a week for this task. Bulk of this
time is to learn about Forrest plugin development.

Although I've put the 'designs for plugins' as a deliverable, it will
be basically something to guide me during the implementation phase
later. This 'design' should ideally decide on the sort of xsl
transformations needed by each plugin.

> The reason I ask is that there is already a DOAP plugin in the
> whiteboard which is reasonably functional (and a little buggy). It works
> with both the skins and the dispatcher and may serve to act as a
> template for how your plugins will look. Then again, you may decide it's
> not quite right.

Actually I was unaware of the DOAP plugin! So during the last couple
of days, I tried to play with it a bit and learn how it works.
Unfortunately, I was not able to get it working with a custom DOAP
file. So, any points or links for documentation regarding this would
be appreciated.

> I like the idea of focussing on a FOAF plugin and using that to gather
> community feedback. I note that you have assigned a considerable amount
> of time to this, but provide very little information about what we can
> expect this plugin to do. For example, is it simply going to transform a
> FOAF file to XDoc or will it also include a number of indexes generated
> from the available FOAF files?

I imagined the FOAF plugin to generate the HTML view of the FOAF data.
However as you suggested we could also generate indexes. What I
understood by these 'indexes', is for example, to use FOAF 'knows'
relationship and give a structural view for the data in the xdocs. Is
that what you meant? If not, please do correct me.

> I'm particularly interested in producing JSON output to enable the FOAF
> data to be viewed with Exhibit (from Simile at MIT). I've started to do
> this in the DOAP plugin, but it is incomplete as other things have got
> in the way. Would you be interested in adding this kind of functionality
> (or finishing it in the DOAP plugin)?

Yes, I also like idea. IMO, producing JSON output off a FOAF will not
be a problem. However, I am not that clear about the relationship
between viewing it in Exhibit and using JSON output with Forrest.
Could it be that you would want the Exhibit like look-and-feel with
Forrest? Or did you mean something else?
With a bit of clarification on this, I am very much interested in
doing this for the FOAF as well as for the DOAP plugins.

> Are you familiar with Forrest already? If not, do you think you can
> grasp what you need to in the time allocated to the first plugin
> deliverable? What approach will you use for getting up to speed with
> Forrest? (don't worry, we are not necessarily looking for people with
> existing Forrest skills)

Development wise obviously I am a total new-comer to Forrest. However
I have used Apache Forrest in building the Apache Woden site couple of
times. That "user" level experience of course is not that much.
However, I believe I could grasp all what is needed and get up to
speed with Forrest by May 31st.

I have already gone through most of the documentation which is
available in the Forrest site, and hope to dive *deep* in to the code
soon! I hope that there will NOT be a huge learning curve and
hopefully with the help of the Forrest community I should be a very
well proficient in Forrest by the end of this project :).

> How did you come across Forrest and why what interests you about this
> GSoC project?

For GSoC, I came across Forrest in the ideas page for ASF.

This project interests me because I believe that it would give me an
opportunity to do an implementation based on the things I have learnt
(FYI, recently I did some considerable study on these various RDF
formats). Also, since I am planning on doing research on Semantic Web
for my grad studies, doing this project would personally help me a lot
in that as well.

> I *love* that you are planning on creating test code for the plugins.
> This is something we do not do enough of in Forrest. There are a number
> of problems with doing tests for Forrest outputs, you may find some
> useful info in a dev archives. Can you provide an outline of how you see
> these tests working.

For the XSLT code, I would first write valid and invalid xml documents
and test those against the XSLT code to see whether it would generate
the desired output. These will act as the examples I mentioned in the

In the documentation, I saw that using WebTest is recommended for
testing during plugin development. Although I haven't used that
framework before, I thought it would be a very good opportunity to
learn and use WebTest.

> It is also worth pointing out that plugins are expected to be documented
> in such a way that the plugin docs themselves are a test case. That is
> they test all functionality.

Yes, I saw how this is done for the projectInfo plugin using use
cases. I believe the similar thing could be done with these plugins as

> For my personal use case I need the plugins to be implemented using the
> Dispatcher, but for Forrest 0.8 release we need the code to be
> compatible with skins. Fortunately it's easy to do this (see the DOAP
> plugin for an example). It is not a requirement of the project to create
> Dispatcher code, in fact, I would be tempted to say that it may be
> better to leave that for the community, thus reducing your learning
> curve. However, if you are already confident with dispatcher or want to
> learn it that would also be fine. Can you please make a note in your
> application indicating what you preference will be (this is for
> evaluation purposes later in the project).

Well, since I am a newcomer to Forrest, I would like to try out with
the skins first.
I would also like to learn about Dispatcher and fulfill your use case.
But at this point I am not so sure of the scope involved. So, I would
take the safe option and not promise to create the dispatcher code.

> Finally, with respect to evaluating your success or failure on the
> program we need to know just how many plugins you intend to implement.
> "Currently it says FOAF + Plugins for DOAP, DOAC, RDF Calendar,
> Microformats, and etc., along with the associated examples", I suggest
> it would be better for you to indicate exactly which plugins you plan to
> implement. Success or failure is not tied to implementing everything,
> just using your time realistically.

Thank you very much for pointing this out. I have now changed the
proposal to reflect when I think each of the plugins would be
delivered. Please advice if this needs any revision.

> One of the goals of GSoC is to introduce new people to the ASF and how
> it works. It appears you do not need this introduction. Can you tell me
> why you feel you should be selected again? What do you feel a second
> year in GSoC will give you? (it is well worth putting this into your app
> as they are rated by the ASF community as a whole, not just the Forrest
> community).

Well, I really like challenges, and GSoC to me in a way, is a big
challenge. I liked doing it last time and I guess I was naturally
drawn to it this time as well. And yes, you are right.. I don't need
an introduction, but I suppose I have lots more to learn! So, I
consider this as a wonderful opportunity to learn new things, test my
skills, interact with a new community and finally deliver something

> How do you propose managing your commitments to GSoC and your work on
> your final exams?

Hmm.. tough one :). Honestly, I do not think I could do much work
before finishing my final exams in mid June. After the exams however,
I am 100% free and could do GSoC work full-time. From last year's
experience, bulk of the implementation work, and thus the
deliverables, happened in-between the mid and the final evaluations,
which according to the GSoC time line this year, falls between July
9th and August 20th. Therefore, if I get accepted,  I would be totally
committed to GSoC during this period.

Also, I would use the period leading up to the mid evals (that is from
April to June) in learning and experimenting with Forrest in order to
deliver the initial FOAF plugin by July 9th.
So I sincerely believe that my university work will not get in the way
of completing the work for GSoC project according to the current

Thank you very much for taking your time to review my proposal.



View raw message