Re: XPe headless user application
From: Sean Gahan (sean_at_optistreams.net)
Date: 08/03/04
- Next message: Slobodan Brcin \(eMVP\): "Re: XPe headless user application"
- Previous message: John Keenan: "Re: XPe headless user application"
- In reply to: John Keenan: "Re: XPe headless user application"
- Next in thread: John Keenan: "Re: XPe headless user application"
- Reply: John Keenan: "Re: XPe headless user application"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 2 Aug 2004 17:35:37 -0700
John,
I don't know if you plan on including the .net framework (don't laugh), but
if you do then you might look at this web server; it is a modified version
of the cassini project from asp.net, you can find it at xpefiles.com:
http://www.xpefiles.com/srOut.cfm?sortid=date&fileid=mss&selectid=109&commentRB=&fileRB=&bothRB=true
with this solution you could have a web interface or use web services. Also
have you looked at Remoting, MSMQ, or COM+. MS recently had a webcast that
covered some of the following topics:
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032256981&Culture=en-US
Regards,
Sean Gahan
"John Keenan" <john.keenan@_removeme_optimapowerware.com> wrote in message
news:cemjru$e5n@dispatch.concentric.net...
> KM,
>
> > Is your target device going to be headless?
>
> Yes.
>
> > Then have you considered RDP option?
>
> I am not completely familiar with the capabilities of RDP. I will have to
> read up on it and experiment with it to determine if it will satisfy my
> immediate needs. However, the application must eventually become a Windows
> service so I am still interested in how to dynamically attached a user
> interface to a headless application running on a remote, headless, XPe
> device.
>
> > Btw, DCOM approach may not be a bad choice if you properly designed...
>
> The application is well architected objects.
>
> > Also, if the communication between the UI and calculation threads are
> simply data transfers...
>
> The communication is not really simple data transfers. It is well
> architected objects talking to each other. I can see how to write
interface
> objects to transform the communication to simple data transfers. I am
> curious if others have found this approach beneficial to DCOM.
>
> John
>
> "KM" <konstmor@nospam_yahoo.com> wrote in message
> news:%23$gEyDNeEHA.3132@TK2MSFTNGP11.phx.gbl...
> > John,
> >
> > Is your target device going to be headless?
> > Then have you considered RDP option? I mean without changes to in your
app
> you can just RDP to the target box and see the app UI and
> > current state.
> >
> > Or did I miss anything from your requirements?
> >
> > Btw, DCOM approach may not be a bad choice if you properly designed your
> app at first place.
> >
> > Also, if the communication between the UI and calculation threads are
> simply data transfers, you can think of two apps network
> > separated. The communication channel between the apps could be
implemented
> with a network named pipe, a TCP/IP connection, a shared
> > mapped file, a database, DCOM, etc.
> >
> > --
> > Regards,
> > KM, BSquare Corp.
> >
> >
> > > I have an existing application with a MFC user interface on one thread
> and
> > > some continuously running calculations on another thread. I am toying
> with
> > > the idea of splitting this application so the continuously running
> > > calculations run as a headless user application on a headless XPe
> system.
> > > The embedded user application would need to support a remote user
> interface
> > > that would connect to it for monitoring and configuration purposes. I
am
> > > trying to determine what options are available for a headless XPe user
> > > application to support a remote user interface (what has worked well;
> what
> > > looked good but added too much overhead to the embedded system; etc.).
> > >
> > > I believe the quickest time-to-market solution would be to place a COM
> > > interface between the existing MFC user interface and the continuously
> > > running calculations. The user interface would become a standalone
> > > application that would use COM to remotely connect to the embedded
user
> > > application.
> > >
> > > An alternative would be for the embedded user application to support a
> web
> > > server allowing a web browser to be the user interface. Of course this
> would
> > > entail new development to support the web interfaces.
> > >
> > > I would appreciate any references/comments/suggestions of these
options
> and
> > > alternative options and their pros and cons.
> > >
> > > John
> >
> >
>
>
- Next message: Slobodan Brcin \(eMVP\): "Re: XPe headless user application"
- Previous message: John Keenan: "Re: XPe headless user application"
- In reply to: John Keenan: "Re: XPe headless user application"
- Next in thread: John Keenan: "Re: XPe headless user application"
- Reply: John Keenan: "Re: XPe headless user application"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
