Re: Re: getting rid of cvsgui protocol

Am 23.01.2004 um 13:47 schrieb kaczoroj:

> 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.

Yes, it's on my list - basically, cvsnt already builds on Mac OS, but I 
need to transfer the modifications for resource fork management before 
it can really be used on the Mac...

However, I doubt that cvsnt actually solves the problem of e.g. ssh 
reporting errors/warnings/information to stdout/stderr, since all cvsnt 
does it to #define printf cvs_printf and thus it conly catches printfs 
_compiled_ into the cvsnt code. (I'd be glad if you prove me wrong here 
;-)

>
>> 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.

One might be able to work around this issue by calling setvbuf on the 
stdout pipe - not sure whether setvbuf works on pipes or not, though...

>
>> 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.

Yes, I agree that a protocol makes things clearer and less error prone 
(as in: have a well-defined protocol instead of interpreting questions 
passed by cvs, parsing output for certain patterns, etc.)
However, since I doubt we'll be able to get the cvsgui protocol into 
each and every implementation of cvs, it means we'd be stuck with 
implementations that actually support the protocol (o.k. - I've read 
your last paragraph, and thus this argument probably doesn't count any 
more ;-)

>
>> 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!

Fine with me - that's exactly why I started this thread: to find out 
about this kind of stuff. Having heard your arguments and this info, 
I'll focus on getting cvsnt working properly for MacCvs rather than 
removing the cvsgui protocol ;-)
All I want in the end is to catch all and every output that's cvs 
related - whether from cvs itself or from one of cvs' child processes 
(ssh, etc.), so the user won't have to guess whether the last line in 
the system console actually relates to the error message in the MacCvs 
console window.
I just experienced this problem yesterday when I wanted to submit my 
changes to sourceforge, but unfortunately, sourceforge was overloaded, 
so 1 out of 3 connection attempts was rejected by the server. 
Unfortunately, this was only written to the system console, since this 
information is provided by ssh (which of course has no clue that cvsgui 
has a #define printf cvs_printf in place ;-)...
Very annoying, since I constantly had to check the system console log 
for additional messages and try to match them up to the entries in the 
MacCvs log window...   arrggghhhh

I'm afraid that kind of problem can only be catched if you actually 
physically redirect the stdout/stderr and pipe them to MacCvs instead 
of relying on compile time redeclarations :(
But again, I'd be glad if someone could prove me wrong on this aspect...

BTW: where do ssh messages end up in WinCvs? Do you get them in the 
WinCvs log, or do they end up in the shell output window?

</jum>


 

------------------------ 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/