Re: [O] Google Summer of Code -- 3 Org projects for our first participation!

[Thorsten Jolitz]

Neil Smithline <address@hidden> writes:

Hi Neil, 

> This is way cool! Recently I have been deeply irritated by the lack of
> a functional server for Emacs Org Mode.
>
> I've run into this problem dealing with the weak presentation of Org
> Mode files on Github. Github uses the Ruby gem org-ruby
> (https://github.com/bdewey/org-ruby) to convert .org files to HTML.
> I've added a feature or two to org-ruby but really feel that trying to
> completely re-implement Org Mode in a Ruby gem is a losing battle.
>
> If I understand the project correctly, a working iOrg could be used to
> support Github's rendering of .org files. Github could just drop the
> use of org-ruby and use iOrg as an external converter for formatting
> .org files.
>
> At the risk of being flamed to a cinder, I'll say that I think that
> using iOrg to support .org files on Github would be a better pilot
> project than Bugpile.

I figured out too that the best way to watch org files on github is raw
mode, so I think this is a very interesting and useful proposal. But its
a bit late for this year ;)

I like the bugpile project, and as I understood it, the bugtracker might
actually be used for Org-mode development if it fits the needs of the
Org-mode hackers. 

Since this years application was such an success with 3 projects
accepted, Org-mode might well try it again in 2013. 
What do you think about putting your proposal on the ideas page for GSoC
2013 (which I could rapidly push to Worg) with you as potential
mentor/co-mentor? 

Then it would not get lost, and interested students could apply next
year (if you can cope with githubs rendering of org files so long). And
there would be much more time to outline and coordinate the project. 

> Besides my personal interest in better Github support for .org, I
> think that the Github project will be generally useful.
>
> Also, from the tone of postings, it sounds like the Bugpile project is
> not well specified. Being that Thorsten only has a summer to do the
> work, I think it will be hard to create a Bugpile specification and
> implementation and an iOrg specification and implementation in just
> one summer.
>
> As Github already has a specification for external markup converters
> (see https://github.com/github/markup), there is no need for writing
> any spec. For the first release of iOrg (ie: this summer's work), the
> iOrg implementation can be simplified to providing .org support for
> Github.
>
> If things go well, I imagine that Thorsten would be very happy to
> finish the summer with his iOrg a part of Github.

Definitely a very interesting idea, but I'm already quite 'invested in
the bugpile project, and imagine I finish the summer as the author of a
bugtracker actually used by a quite big and dynamic GNU project like Org-mode.

> Just my two cents,
>
> Neil
>
> PS: And the answer is "Yes. I am aware that vehemently suggesting a
> project is equivalent to offering to help with it." :-D
>
> I can help with the .org/Github side of the project though I'm sure
> others know more about the implementation of Org Mode than me. If
> needed, I could also help manage interactions between Thorsten and
> Github as I'm sure that Github will have some requirements before they
> accept a pull request into their repository.
>
> As far as Emacs internals, it's been 25 years since I last looked at
> the C source for Emacs so there must be better folk than I. In any
> case, any Emacs internal work that must be done for iOrg existed prior
> to my suggestion. In other words, it ain't my problem ;-)
>
>
> Neil Smithline
> http://www.neilsmithline.com
> Proud GNU Emacs user since 1986, v. 18.24.
>
>
> On 4/24 04:12 , Thorsten wrote:
>> Ian Barton <address@hidden> writes:
>>
>>>> Bugpile - a bugtracker for GNU Emacs Org-mode written in Elisp and
>>>> Org-mode (Thorsten)
>>>>
>>>>     The Bugpile project has two goals: 1. Develop a bugtracker (called
>>>>     Bugpile) for GNU Emacs Org-mode, using Elisp, Elnode, Org-mode, and a
>>>>     dVCS. 2. As part of the engineering process, abstract out a
>>>>     web-framework (called iOrg) based on these GNU Emacs technologies. A
>>>>     web-framework written in Elisp, with Org files used for database
>>>>     functionality, is a new approach that enables interactive web
>>>>     applications built on top of GNU Emacs. Bugpile is an example
>>>>     application, but useful in itself.
>>>>
>>>
>>> Great news!
>>>
>>> For the dim witted (me) can you explain if Bugpile is meant to be a
>>> bug tracker specifically for tracking bugs in Emacs and org, or can it
>>> be used as a generic bug tracker for any project.
>>
>> Thats a very interesting question, since there are two somehow
>> conflicting goals involved.
>>
>> The original project idea was to extend Org-mode for a more interactive
>> kind of web-programming, i.e. having buttons and forms on your webpages
>> and a kind of database in the background that stores changing state, and
>> some logic that reacts to user action (instead of just publishing static
>> web content).
>>
>> Bugpile is kind of a (useful) pilot project for this idea, and during its
>> development an Emacs/Org-mode based web-framework (iOrg=interactive Org)
>> should emerge.
>>
>> Because this is about interactive web programming, bugpile should be
>> rather generic and accessible for anybody - they don't need Emacs, they
>> can use the web UI. A web-based bugtracker is nothing new, one could
>> just choose one out of several free tools on the market. The exciting
>> thing is being able to write one based on Org-mode and other Emacs
>> libraries like Elnode, i.e. developing the web-frameworg iOrg.
>>
>> On the other hand, Emacs user don't like to use web-interfaces, they
>> want to use Emacs to interact with the application. Thus the USP of
>> bugpile could be that it is not only written on top of Emacs, but can be
>> efficiently used from inside Emacs.
>>
>> Since time is limited, the main goal of the project is to develop the
>> iOrg webframework and the generic webbased bugtracker bugpile as a
>> tangible pilot project/ proof of concept. An optional, but highly
>> desirable additional output would be a Magit-like bugpile-mode for
>> Emacs. But I would prefer to keep it optional to limit the scope of my
>> GSoC project.
>>
>> This is still not defined, I would be happy about some community
>> feedback, and will of course discuss with my mentor(s).

-- 
cheers,
Thorsten