Re: [DotGNU]Jabber.NET

[Gopal V]

If memory serves me right, Simon Guindon wrote:
> ./jabber/connection/IQTracker.cs:123: no matching method for call to
> `WaitOne(int, bool)'
> ./jabber/connection/IQTracker.cs:123: invalid operand to unary `!'

/me looks at Tum who did the WaitHandle stuff ...

I think I could fix the methods just for fun and make it compile,
but it won't work without fixing the internal calls .. I need help !.

Because 2 of the WaitOne methods seem to accept a "bool exitContext" as 
well according to docs hosted on minddog's box .. 

Some of those methods are non-ECMA , could you mark them out in
the classes and tests ?..

> ./jabber/server/JabberService.cs:191: could not coerce constant argument 1

Moving onto fixing this ...

> Most of those seem to be Threading stubs not existing?

Added those ..

> I guess after these compiler issues are resolved, we have to start thinking
> about class lib implementation.  Two things come to mind, first is
> System.Xml, but I'm not too worried about that, I will try and organize test
> cases and such for that and try and help develop and work with minddog.

I've almost got it building .... you should maybe figure out a way to
test the jabber/protocol/* first ?.

An initial look there was promising and I think we could fake threading
to test that ;-) ... like executing ThreadPool requests synchronously.
Things like that might affect re-draw of GUI apps in general , but won't 
matter much for command line apps right now. Also the interlocked variables 
can easily be faked for one single thread :-).

I think you should be able to start testing that region sooner or later.
But well confirm my comments with Joe , I might be just too wrong.

> The other major issue, which is the largest thing lingering over Jabber.NET
> compatibility is Threading, I know Rhys is busy with a great many things
> (including work) and from his statements theres no clear solution yet.
> Maybe we can try and brainstorm a little on this topic and see what arises?

Is there any developer who wants to take this up ? .. It would be a lot of
little things to fix in almost all internal calls .. rather than a single
huge patch to a function.

Maybe we should place a 5 day window for an unstable tree in CVS and 
fix segfaults in parallel as we find each place where locks are needed ?.
Otherwise it soon becomes a single man task ...

Gopal
-- 
The difference between insanity and genius is measured by success