[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
RE: UIDs
- Subject: RE: UIDs
- From: Kevin Hawkins
- Date: Wed, 11 Jun 2003 13:04:00 +0000
My view is the separate UID's (deviceID) for each app within your container
- plus a UID for the container - after all a component could fail and the
container still continue so separate heartbeats are necessary for each
xAPp.
I know then it doesn't become obvious from the UID's that one is a
container
for the others - you could sort of use FF00 to FFFF for this though. ??
thinking aloud ??
I actually have a similar situation with C-Bus - should each switchplate
and dimmer pack have it's own UID and then each output a hardware sub
(ideal) or should the C-Bus gateway xAP have just one UID - or even should
the C-Bus lighting have one UID and C-Bus Security say another. In a way my
C-Bus gateway is a container for a load of xAPp devices which in themselves
have hardware subs - I need a three level hierarchy too - I am using this
FFxx approach currently - maybe we should have this as a sort of policy
usage/understanding.
Kevin
> -----Original Message-----
> From: Stuart Booth [mailto:<a
href="/group/xAP_developer/post?postID=4hBRBuqHpcieJPpfCE-uoKU92RHjdhID02ZgPhXxSDKehkE2X1_BVO-vekajsWV91WOHl1ctLKoGVI_0gvvtKw">lists@x...</a>]
> Sent: 11 June 2003 11:24
> To: <a
href="/group/xAP_developer/post?postID=BzYC5RP-59q4MrfDl-qtXX1lWMiphV65mUlMl1bQlCXd0tGsLMo2gP8KKA8AtdPsWVku7vtcj1GFb606upWXf8Y1S-QQ">xAP_developer@xxxxxxx</a>
> Subject: Re: [xAP_developer] UIDs
>
> On Wed, 11 Jun 2003 00:49:52 +0100, "Kevin Hawkins"
> <<a
href="/group/xAP_developer/post?postID=mnZD3kRtqKn6_MHXdtXEeztUbYkJCk1QN3S1DDEiuY-IIG-qFGAojSqldWtbhWjlEGd4WW3uF3riv1IvFA">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&development
modules in
> standalone console containers so that they don't interfere with the
> good & 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=WD9H4SnNVTRzsQcO8NygZrmH_CjlR-B0pYwlVLwCeDbf6bcKdXL6fEqob5fS_dl6Zr2RjaeypQWcVxWnYghFCA">stuart@x...</a>
>
> ------------------------ Yahoo! Groups Sponsor
---------------------~--
> >
> Get A Free Psychic Reading! Your Online Answer To Life's Important
> Questions.
> <a href="http://us.click.yahoo.com/Lj3uPC/Me7FAA/ySSFAA/dpFolB/TM">http://us.click.yahoo.com/Lj3uPC/Me7FAA/ySSFAA/dpFolB/TM</a>
>
---------------------------------------------------------------------~-
> >
>
> To unsubscribe from this group, send an email to:
> <a
href="/group/xAP_developer/post?postID=HICyJZL8cS5HALtYsVwviN6HIZojF5oQWObNSQ8amMer6VrQU1QTQa_aNWMYaPVcPgnDSGX7lDuI1Wqz2syz_6faFIENXyQP_BTazsYwJ98L">xAP_developer-unsubscribe@xxxxxxx</a>
>
>
>
> Your use of Yahoo! Groups is subject to
> <a href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</a>
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|