git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Pau Garcia i Quiles <pgquiles@elpauer.org>
Cc: git@vger.kernel.org, John Hawley <warthog9@kernel.org>,
	Kevin Cernekee <cernekee@gmail.com>, Petr Baudis <pasky@suse.cz>,
	Petr Baudis <pasky@ucw.cz>
Subject: Re: The future of gitweb - part 2: JavaScript
Date: Mon, 18 Apr 2011 20:13:13 +0200	[thread overview]
Message-ID: <201104182013.14475.jnareb@gmail.com> (raw)
In-Reply-To: <BANLkTin80KQzp9=2Bu4rxJSwcnUj-aXaHw@mail.gmail.com>

On Sun, 17 Apr 2011, Pau Garcia i Quiles wrote:
> On Sun, Apr 17, 2011 at 4:59 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> 
>>> My suggestion is going to be tremendously unpopular, but still: if I
>>> were to develop my own gitweb, I'd use Wt ( http://webtoolkit.eu ) +
>>> libgit2. In fact, there is a very basic gitweb-like example bundled
>>> with Wt sources, it's available online at
>>> http://www.webtoolkit.eu/wt/examples/git
>>
>> Well, nothing prevents you or anybody else from writing (yet another)
>> web interface in C++ + Wt + libgit2.
> 
> I do not have the slightest intention of doing that, at least not in
> my spare time. The existing interfaces (gitweb, cgit, etc) are good 
> enough for me. 

I can certainly understand that... ;-)

> I made the suggestion of going with Wt just in case a 
> rewrite of gitweb was in mind.

No, major rewrite of gitweb is certainly not on agenda.  Besides IMVVHO
rewriting a long-lived existing application / project from scratch is
usually a bad idea; you would almost certainly repeat old mistakes.
If code is bad enough that it hinders maintenance and development, it is
better to do refactoring, trying to keep project working as it was.

The question was more about future features.

[...]
>> BTW. do I understand correctly that Wt generates JavaScript code, in
>> similar vein to GWT for Java, or Pyjamas for Python?
> 
> Wt generates Javascript only if the visitor has Javascript enabled. If
> Javascript is not available, it will generate plain HTML pages, with
> "update" buttons, etc and it will do that automatically: there is no
> need for you to write code "if Javascript is available { ... } else {
> ... }".

Well, actually sometimes you need to know if JavaScript is available...
for example in the case of gitweb there is separate 'blame' view which
runs 'git blame --porcelain' which can take a while, and Ajax-y
'blame_incremental' which runs 'git cat-file -p' + 'git blame --incremental'
in background via XmlHttpRequest.  Different server-side reactions;
and doing both would be really counterproductive wrt. performance.
 
On the other hand it would be nice to write almost the same algorithm
of parsing 'git blame --porcelain' and 'git blame --incremental' output,
and of generating or manipulating output to the same look ONCE, and not
one time in Perl, one time in JavaScript.


Unfortunately I haven't found anything on CPAN that would be Perl
equivalent of Java's GWT, C++'s Wt, or Python's Pyjamas... well except
not quite here CGI::Ajax.  Besides even using CGI::Ajax goes against
current "no non-core dependencies" policy...

BTW. there is Continuity Perl web framework which I think is similar
to Wt in that it manages state of web app like Wt does.

> The advantage of Wt is you can compile a hypothetical gitwebwt as a
> static executable and the result will be a single executable file that
> depends only on libc (or libc + git, if you call git instead of
> linking to libgit.a or libgit2). Also, performance and memory
> requirements are very good, which is important for not-that-powerful
> devices such as routers, etc.

Nice.

-- 
Jakub Narebski
Poland

  reply	other threads:[~2011-04-18 18:13 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-14 19:39 The future of gitweb (long term goals) Jakub Narebski
2011-02-15  9:09 ` Michael J Gruber
2011-02-21 22:06   ` Jakub Narebski
2011-02-23 10:54     ` Michael J Gruber
2011-02-25 22:37       ` The future of git-instaweb (was: Re: The future of gitweb (long term goals)) Jakub Narebski
2011-02-22 17:02 ` The future of gitweb (long term goals) Ævar Arnfjörð Bjarmason
2011-02-22 18:17   ` Jakub Narebski
2011-04-14  9:54 ` The future of gitweb - part 2: JavaScript Jakub Narebski
2011-04-14 19:30   ` Michał Łowicki
2011-04-15  1:56     ` david
2011-04-16 17:12   ` Peter Vereshagin
2011-04-16 19:32     ` Jakub Narebski
2011-04-16 20:48       ` Peter Vereshagin
2011-04-16 21:17         ` Jakub Narebski
2011-04-16 21:53           ` Peter Vereshagin
2011-04-16 22:19             ` Jakub Narebski
2011-04-16 22:33               ` Jakub Narebski
2011-04-16 23:00               ` Peter Vereshagin
2011-04-17 10:11                 ` Jakub Narebski
2011-04-20 18:24                   ` Gitweb != HTTP back-end {Was: Re: The future of gitweb - part 2: JavaScript} Drew Northup
2011-04-20 18:47                     ` Jakub Narebski
2011-04-16 17:44   ` The future of gitweb - part 2: JavaScript Pau Garcia i Quiles
2011-04-17 14:59     ` Jakub Narebski
2011-04-17 15:14       ` Pau Garcia i Quiles
2011-04-18 18:13         ` Jakub Narebski [this message]
2011-04-17 20:14   ` Petr Baudis
2011-04-18 13:34     ` Jakub Narebski
2011-04-18 13:50       ` Petr Baudis
2011-04-18 14:15         ` Jakub Narebski
2011-04-20 18:39   ` Drew Northup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201104182013.14475.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=cernekee@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=pasky@suse.cz \
    --cc=pasky@ucw.cz \
    --cc=pgquiles@elpauer.org \
    --cc=warthog9@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).