On Sat, 2009-07-11 at 13:35 +0200, David Eriksson wrote: > [Sorry for dupes of this.] > > Hi, > > First of all, it's wonderful to hear that you make good use of SynCE. I > would really appreciate if you are able share some more about the > context you use SynCE in, either to the list or privately. (It's great > to see one's kids grow up > > I think that you should model the new RAPI interface after the Microsoft > RAPI2 Interface (IRAPIDevice, IRAPISession, etc): > > http://msdn.microsoft.com/en-us/library/aa922133.aspx > > MS buils these interfaces on top of the Component Object Model (COM) so > C++ would be a natural fit, but if you implement it in C for easier Ruby > bindings that's fine. Just add "this" (or "self" :-) as first parameter. > (I would have implemented the original librapi2 in C++
I'm glad you didn't, I probably wouldn't have bothered fiddling with it :) > if it wasn't > because I hoped that language bindings would be easier with a C > interface.) > > In the C interface I suggest that you do like this, or something close > that makes it easy for the Ruby bindings: > > HRESULT RAPIDevice_CreateSession( > RAPIDevice* self; > RAPISession** ppISession > ); > > BOOL RAPISession_CeCopyFile( > RAPISession* self, > LPCWSTR lpExistingFileName, > LPCWSTR lpNewFileName, > BOOL bFailIfExists > ); > David, this is a magnificent idea ! And it's relatively easy to implement I think. David (Richardson), if this sounds of interest, here's how I would see this working. Currently all rapi calls start in rapi_indirection.c, where the current context is fetched, and used to call the appropriate function, in rapi/ or rapi2 subdirs, through the rapi_ops struct. Initially we change the "real" functions in these subdirs to accept the context as the first parameter, which we pass through from the call in rapi_indirection.c. At this point the original API is intact, but we have a working body of functions that accept any context we pass. Now it should be possible to implement a new public API in the manner David shows, that can call these functions using the context from the RapiSession pointer we pass. Does that make sense ? I think I'm going to give this a go, though I want to do another release first, so it won't be straight away. > Locking (per session) should really be done inside the RAPI calls, not > outside. > Yes, I think each context needs internal locking, but I'm not sure how this should be done. Can we just use pthread mutexes ? > Reference counting could be implemented just like AddRef and Release > from IUnknown in COM... :-) > > > > Best regards, > > David Eriksson, http://www.divideandconquer.se/ > > > On Fri, 2009-07-10 at 17:06 -0700, David Richardson wrote: > > I'm using librapi for some really cool testing framework stuff at > > Flexilis. I'm really trying to push the limits of the library. I've > > wrapped librapi in ruby using Ruby::DL but currently I have to mutex > > on any RAPI call. I'd really like to only have to mutex per-device. > > Ruby only uses green threads so the existing thread safe stuff isn't > > going to help me, I believe. I want to run tests on hundreds of > > devices in parallel. > > > > What I want to do is create alternative wrappers for each RAPI > > function where I pass the context in as the last parameter, rather > > than specifying it ahead of time with . I tried some initial > > experimentation with this yesterday, but didn't have much luck. > > Before I dive too deep into it, I wanted to make my proposal and hear > > any comments you have. Specifically I'm concerned about how the > > contexts work and when/how they become invalidated. > > > > Serially I will create each connection (rapi_connection_from_name), > > select it (rapi_connection_select), initialize it (CeRapiInit) and > > store the current context (get_current_context). Then in parallel I > > will call modified RAPI functions on hundreds of devices that take the > > context in as a paramater. > > > > I notice that the act of selecting a connection unref's the previously > > selected connection and destroys it (since this was the only > > reference). Is it sufficient for me to just store a reference to each > > context and call rapi_context_ref (and unref when I'm done)? Is there > > anything else that would invalidate the previous context? > > > > I'll hopefully be experimenting with this sometime next week. Is this > > a change that others would be interested in contributing toward > > librapi's trunk? Do you have a suggestion of a better way to go > > about this? Is there maybe some existing functionality that I'm > > missing that already allows this? > > > > Thanks! > > -David Richardson > > Flexilis Mobile Security > > > > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > SynCE-Devel mailing list > SynCE-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/synce-devel
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge
_______________________________________________ SynCE-Devel mailing list SynCE-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel
