Re: UIDs

[Stuart Booth]

On Wed, 11 Jun 2003 00:49:52 +0100, "Kevin Hawkins"
<<a
href="/group/xAP_developer/post?postID=aAyaDK3vTlyQyegKx7vMnQmhVLj2WGum0C-ICZolVGC5nyG5cXAIRsUqWeMZNtoxkx0JH2QJZZTOvV4dFaAiVYM">lists@u...</a>>
wrote:

>In which case I believe each plugin should have its own UID ie the
centre 4
>hex values should be different for each plugin - separate hardware subs
>should NOT generate individual heartbeats. Separate xAP applications
should.

Just to clarify, in this case it's just *one* application, which loads
multiple sub-components. There is only one EXE. That's why I thought
to use different subaddress values. But I'm easy either way. I'll make
sure I'm doing it the right way before I release it shortly.

> > Each 'plugin' increments this UID subaddress node by 1, but
shares the
> > DeviceID, which I believe is correct. So SliMP3Connector is
FF123401,
> > and CallerID-OSD is FF123402, etc.
[munch]
> In your example above effectively your SliMP3 and your CallerID are
>becoming hardware subs - which I am not sure is incorrect (they are
hardware
>devices as such) but a news connector really shouldn't appear as such,
which
>I am thinking in your setup it would.

That's correct, it would. Each module is a bit of xAP logic that
receives messages from the 'container' application (a standard user
interface EXE application), generates its own heartbeat, and does its
own thing, utterly independently of any other loaded modules.

At the moment I've only implemented my SliMP3 connector and the
CallerID OSD generation app (not the Meteor i/f) in this manner, but
things like News and Meteor interfacing will come along shortly once I
know it all works just fine.

>Your situation is complicated by the fact thatt you have a container
>application that (could) contain other software applications - a sort
of
>hierarchy taht I hadn't anticipated - further clouded by the fact that
the
>SliMP3 and CID are hardware - do you need this hierarchy - I am leaning
>towards all software xAP's - and that includes xAPp's with one hardware
>endpoint eg the CID or SliMP3 should end their UID in 00 and not use
>hardware subs.

Yup! I reckon I do need this way of executing things. For instance,
the UI component of the application is just repeated code. For each
xAP application I can do a Windows Service, a Console mode application
and a Windows GUI based application. That's a lot of repetition and a
lot more maintenance.

Also I have about 6 xAPps running on my Server, all with their own
separate display window. It looks a bit nasty tbh.

With this 'new' xAPFramework.net supported architecture, I have 3
'standard' user interface modules, implementing a generic service
console mode app and GUI app.

And I also have the separate xAP logic modules, implemented once, and
loaded in any type of configuration the user wishes. I can combine
multiple modules into one application or run them separately. I can
mix and match them together, running some that work well as services,
others in GUI 'containers', and brand new test&amp;development modules
in
standalone console containers so that they don't interfere with the
good &amp; solid ones.

Separate DeviceIDs rather than SubAddressNodes works for me. I'll do
whatever's correct. Intuitively using SubAddressNodes appealed because
there is only one EXE, and that EXE has different modules loaded that
can't necessarily run on their own.

S
--
Stuart Booth
xAPFramework.net - a reusable xAP framework for .net

<a href="http://www.xapframework.net/";>http://www.xapframework.net/</a>
<a
href="/group/xAP_developer/post?postID=JjONqvup2JviMiDQ8XQDnpA2VXViEn_8Dmki6OsUlMA4eXndULYhgk1B7Mjvn7atvryK6f-lez8t5pT_LUhGXAtA">stuart@x...</a>