git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org, John Hawley <warthog9@kernel.org>
Subject: Re: The future of gitweb (long term goals)
Date: Tue, 22 Feb 2011 18:02:09 +0100	[thread overview]
Message-ID: <AANLkTin9dWXkaxqLdiosx-=jA9gbEqoJ8aAFoZMU94ih@mail.gmail.com> (raw)
In-Reply-To: <201102142039.59416.jnareb@gmail.com>

On Mon, Feb 14, 2011 at 20:39, Jakub Narebski <jnareb@gmail.com> wrote:
> This means that we are not able to use web (micro)framework, or use
> templating engine to create HTML instead of combination of CGI.pm
> methods and handcrafted HTML (worrying about proper escaping), or just
> use CGI::Cache or Plack::Middleware::Cache for adding output caching
> to gitweb.  Though if one wants web interface in Perl that uses web
> framework (and is supposedly backwards-compatible with gitweb URLs),
> there is always Gitalist which uses Catalyst web framework.
>
> On the other hand requiring non-core Perl modules means that gitweb
> installation would be harder.  We can work around this issue if there
> are a few small such modules (e.g. using Exception::Class or
> HTTP::Exception as base class for gitweb error handling) by putting
> them in 'inc/' and installing local version if they are not present,
> like Git.pm does with local Error.pm module.  But for microframework,
> or templating engine, or e.g. Plack (if we go the route to make gitweb
> PSGI application) this would be rather out of question.  Anyway, in
> any case gitweb would probably require more complicated build system
> than current one... but moving to e.g. ExtUtils::MakeMaker shouldn't
> be that hard (see how Git.pm does it, only we can require Perl 5.8.3
> which has new enough EU::MM that supports DESTDIR).

Why do you think that if we use larger modules these things would get
harder?

There's already applications on the CPAN which can do "fat
packing". I.e. you could use Plack, Catalyst, Template and whatever
else but run some make target to pack gitweb and all its dependencies
into a single file.

Obviously it would be really big, and probably slow unless you ran it
as a fastcgi script. But that would be a tradeoff for making the
source easier to maintain.

But packing things like these is not a technical challange at all, and
probably way easier than reinventing the wheel each time you need some
small thing that's not in core, but is in a popular & well tested CPAN
module.

  parent reply	other threads:[~2011-02-22 17:02 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 ` Ævar Arnfjörð Bjarmason [this message]
2011-02-22 18:17   ` The future of gitweb (long term goals) 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
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='AANLkTin9dWXkaxqLdiosx-=jA9gbEqoJ8aAFoZMU94ih@mail.gmail.com' \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    --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).