Re: getting rid of cvsgui protocol

Jens,

> When I asked Tony how he solved this problem in cvsnt he hinted 
> me towards the possibibility of not using the cvsgui protocol 
> alltogether and rather just redirect stdio to a pipe where MacCvs 
> can collect all stdio output...

Either that, or just use CVSNT which has all output tunneled for 
cvsgui protocol already, not to mention all the features it provides 
over the standard CVS.

> I then investigated this approach and actually, it looks like 
> there's no real need for the cvsgui protocol at all on Unix 
> flavored platforms, 

It can also be done on Windows without cvsgui protocol. But using 
protocol does offer advantages both currently and in the future 
potentially. 

One of advantages is more natural buffering of output. Typically OS 
will attempt to buffer pipe opeations and flush that at it's own will 
or at the point it's flushed programmatically (e.g. by using fflush()) 
while the console screen is flushed whenever a newline character is 
printed. When using pipes to intercept the output of console 
application you will always run into buffering "feature" which results 
in weird behavior like command running with no visible output for some 
time and then having an couple of kB suddenly going thru the screen.

> since all the cvsgui protocol does (AFAICS) is:
> 
> 	- catch output from cvs
> 	- provide environment variables
> 	- detect cvs termination

There is large potential in extending protocol usage, like providing 
more detailed information to make message boxes more descriptive 
(CVSNT already supports that and we only have to "intercept" it in 
protocol) or passing long command lines without reaching the OS 
limits. It essentially offers easy way to create interactive API.

> All of those can be solved using standard APIs (pipes, execve, 
> wait_pid) and thus I think we could get rid of the cvsgui 
> protocol at least on those platforms that support those means of 
> implementing the requirements.

I am sure all platform can intercept command's ouput, but protocol has 
it's advantages.

> do you think it would be too much difference in handling cvs 
> execution if MacCvs (and probably also gCvs) wouldn't use the 
> cvsgui protocol?
> (Getting rid of the cvsgui protocol would also allow to 
> use 'regular' cvs distributions, or actually _any_ cvs 
> distribution for that matter.)

And here is the time for a surprise ending... ;)

After we get the stable WinCvs out we will be adding support for 
non-cvsgui protocol CVS client. So, in the end it's not about removing 
protocol but rather extending it to also handle non-compliant CVS 
client. It's good to have the interception code in one place and some 
code can be shared for both types of clients. It will also provide 
simple interface for all platforms. The protocol callbacks will be 
used for both interception methods so it will nicely tunnel and fit in 
the current code without creating too much special cases.

In other words: don't get rid of it, extend it!

Best Regards,
Jerzy


 

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
Printer at MyInks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/NhFolB/TM
---------------------------------------------------------------------~->

Yahoo! Groups Links

To visit your group on the web, go to:
 http://groups.yahoo.com/group/cvsgui-dev/

To unsubscribe from this group, send an email to:
 [email protected]

Your use of Yahoo! Groups is subject to:
 http://docs.yahoo.com/info/terms/