Duh... <hand slaps head> ;-)  

I am assuming that I could use raw sockets, noi?  So possibly just step a little
lower to ecore_con and transfer the bits that way?

Thanks again,
Jess


On Sun, Aug 03, 2008 at 07:53:14PM -0500, Jess wrote:
> Hey Raster,
>   
> On Mon, Aug 04, 2008 at 08:38:44AM +1000, Carsten Haitzler wrote:
> > On Sun, 3 Aug 2008 16:36:58 -0500 Jess <[EMAIL PROTECTED]> babbled:
> > 
> > > Hello All,
> > >   I have used Ecore_IPC recently to allow two of my EFL based apps to 
> > > inter
> > > communicate.  I had not previously used IPC very much (some of the sample 
> > > apps
> > > from Stevens, and a few small tasks), and really started using the Ecore 
> > > libs
> > > as they seemed very easy to use, and didn't require a ton of work on my
> > > part.  I have been asked by a new customer to provide information on cross
> > > platform IPC solutions (I think they have a stronger wintel background), 
> > > but
> > > so far have not been able to find anything truly cross platform, which 
> > > made
> > > me wonder if the Ecore_IPC has been released on the Wintel platform, and 
> > > if
> > > so, what the differences are under the hood, as well as how portable 
> > > coding
> > > would be.  Does anyone know if this has indeed been ported? 
> > 
> > cross-platform? is this ipc between 2 hosts of different os type? or within
> > processes of a host (and if its efl.. i know win32 ports, bindings and 
> > efforts
> > are going on and it works.. but it's still immature), so i assume the os 
> > would
> > be unix (of some sort) in which case... you have a wealth of ipc mechanisms.
> > the ones efl "blesses" are:
> > 
> Well, I am new to their system, and am providing evaluations of systems and
> processes to get them off of their SOC platform, and using Linux on ARM 
> embedded
> boards, and the discussion of IPC came up, and of course I said "Yes, I have 
> done that, using the EFL!" ;-), but once they started talking about Win32 
> they 
> lost me, so I am thinking they may be testing their code on their desktops, 
> and 
> then putting that code into a current SOC implementation (is that 
> possible???),
> and want to migrate it with minimal effort.  The information I currently have 
> is pretty vague.  It could be between hosts, as they do implement a sort of 
> networking between remote units and a base station (via 900Mhz if it matters),
> but I have not yet gotten the in's and out's tour of their setup.
> 
> > 1. unix/tcp sockets (raw - just data) - ecore_con
> > 2. ipc over sockets (ecore_ipc - builds on top of ecore_con).
> > 3. signals (sigusr1/2/whatever) - ecore itself wraps these as events. and u
> > have the system kill() call to "send" them
> > 4. dbus (edbus links libdbus into the efl main loop and provides lots of
> > convenience stuff - this is a socket-based ipc mechanism).
> > 5. simple file descriptors (ecore_fd_handlers handle traffic on these) so 
> > you
> > need something that provides you with read/write fd's (a library). and 
> > pretty
> > much every library out there that does ipc of some sort should do this
> > 
> > not sure how much more you need, but 2 unix mechanisms for ipc that are not
> > "blessed" by efl (i.e have no direct support so you are "on your own"):
> > 
> > sysvipc
> > sysvshm
> > 
> > to be honest... no one uses sysvipc.. that i know of (seriously uses it). 
> > and
> > syvshm's largest user as best i can tell is xshm (the x shared memory
> > extension) used for transferring data to/from x (image/pixel data) without
> > doing a copy.
> > 
> Ok, that actually clarifies a couple of other things as well ;-).
> 
> Let me change the question a little bit.  If I were to have an 
> application and use the Ecore IPC, would it be possible to communicate with a
> Win32 host for IPC related tasks?  What would the connection on the other end 
> look like in terms of required libraries, code, etc?  As the port to Windows
> may still be lacking in terms of maturity, are there other alternatives that
> exist?  In terms of the Ecore IPC, is this standards based in terms of how it 
> communicates, and futher, is this a standard that would exist, or be 
> implemented
> in a Win32 API?
> 
> 
> I will try and get more information tomorrow about this, as your questions 
> have
> highlighted some unknowns that may be problematic ;-) .
> 
> 
> > -- 
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > The Rasterman (Carsten Haitzler)    [EMAIL PROTECTED]
> > 
> Thanks Raster!
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> enlightenment-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to