Re: ls*, markup and other things

[Wang J. <la...@li...>]

Hello Alexey,



Saturday, May 04, 2002, 10:32:41 PM, you wrote:

AM> Well, yesterday I committed lsmodules subcommand so everyone are welcome
AM> to test it :-). Together w/ ls, lsacl and forthcoming lstags (Alex,
AM> don't shy as you said me a while ago, commit it please :-)) there's a
AM> complete (hopefully) bunch of commands that implements a kind of listing
AM> server (well, Michael, it's not completely 'httpd'-server as you asked
AM> but it's enough to build a remote web-frontend).

AM> I have already implemented a kind of such frontend based in CVS::Remote
AM> perl module and I hope I'll turn it eventually into viable replacement
AM> of the cvsweb and similar programs).

AM> There's an issue I want to discuss though. Current format of ls*
AM> commands are humanly readable and understandable but they can be more,
AM> hmm, formalized or smth (especially lsacl, but ls also has portability
AM> bottlenecks and so on). So my question is:
AM> do we need these commands to have an, hmm, XML-like output? If yes,
AM> what's the DTD? There're pros (we won't need an unique parser for each
AM> command) and cons (the server code needs to be more complex, there will
AM> be greater output size and so on) so final decision should be carefully
AM> discussed.

I don't think output of XML-like format is good. The pros doesn't buy
cons.

AM> Now I'm going to commit cvs-create-repository and cvs-group
AM> commands. Alex, where's the best place to put such things?

AM> A while ago my Novosoft bosses (actually it's Marod :-)) told that would
AM> be fine to have a workaround against one well-known cvs (librcs)
AM> bottleneck: when file processing time dramatically increases when
AM> there're long/complicated commit history. One possible solution for the
AM> problem is to implement (in a separated utility) a kind of purge/merge
AM> operation. This will allow us to remain compatible w/ stock cvs and
AM> solve some of the problems. The question: is there another, more
AM> convenient way? Or we should change the repository format instead and
AM> solve the problem completely?..


-- 
  lark