Re: xPL-Issue

[Mal Lansell <mal@xxxxxxxxxxx>]

I'd have replied to this thread sooner, but a stag weekend in Newcastle
got in the way.  Sadly it will be my last one unless any of my friends
get divorced and remarried (although my liver could probably do without
another weekend like that!)

Is the problem just that xPLHal won't work if it doesn't manage to
create it's hub?  If so, that's a bug in xPLHal and nothing to do with
other hubs - V3 or not.  If it can't make a hub because the port is
occupied, it should just retry every so often, not fail the whole app.

Personally I don't agree with all this multiple hub malarky.  The only
reason my W800 service has a V3 hub is because after some debate (but as
far as I recall no actual agreement) the .NET library was released with
the hub/mutex system included, and so I had to go along with the idea in
the C++ SDK (used by the W800 service) just for the sake of compatibility.

I can see why the automatic transferrable hub may have initial appeal -
the user can just download an xPL app and it should work, but I'm still
convinced that a single stand-alone hub would be a better solution.
There is no reason why the stand-alone hub could not be included in the
install package in the same way that a computer game includes DirectX -
if the current version is out of date (or missing), the installer gives
you the option of installing the version included with the application.

Talk of needing a "bulletproof" stand-alone hub is bogus - a V3
hub
needs to be just as stable as any stand-alone hub since not all failure
modes will result in a crash or release of mutex (or the xPL port for
that matter).  A hub either works or it doesn't - if it doesn't, it
needs to be fixed.  If there were only one hub application, it would be
far easier to maintain.

Mal



Ian Lowe wrote:

>
> This particular problem simply didn't happen when a separate hub was
> mandated - the appearance of the v3 library which allows apps to be a
> hub in and of themselves introduced  the scenario (which, as you say,
> seems to be coming up more and more now) where the order of services
> starting matters. Not ever time, but often enough to cause the issues
> that Frank and I have seen.
>
> As I see it, there are one of two things at play - either there is a
> simple bug within the v3 code which causes it's hub to not work
> correctly, in which case it probably needs an effort from all users to
> help Tom find the issue by gathering as much info as possible - the
> circumstances of failure, what happens *exactly* - that sort of thing.
>
> The other option, is that this is a basic flaw within interoperation
> between code that's going to use the v3 style mutex, and code that
isn't
> - basically, any of the OCX based apps, or pre-v3 code.
>
> Mal's W800 app seems to have also caused this problem to be exhibited,
> so which codebase is it using? V3, or something else? If something
else,
> is it using mutexes or not?
>
> One thing is clear - we have an interoperability bug that's appearing
> often enough to be a confirmable bug, rather than just the odd
> misbehaving episode...
>
> I wrote a simple app (part of our helpdesk environment here at work)
> using the v3 code, and it's a nice to use tool - I don't, however, see
> the inbuilt hub functionality as required, and I wonder if it's time
to
> remove this from the library - I don't see it as being an option to
> simply say that everyone else (ie xplhal, or any ocx based software,
or
> the xpl4java environment) has to change their implementations to use
v3
> style mutexes - this problem only appeared with the v3 .net library,
so
> I think that *it* needs to be fixed here!
>
> I can't recall who it was that said at the time (might have been Mal)
> this was originally debated, that it would be preferable to have an
> absolutely rock solid Hub service, and just insist that it's installed
> before other services etc can be used, rather than have a variety of
> applications that might or might not become hubs.
>
> Can we have some opinions on this please?
>
> Ian.