[missing-sync-palmos-dev-talk] Re: Requests

[Scott Gruby]

[Mark, I'm replying to the list as I'm sure others are quite 
interested.]

On Apr 22, 2004, at 7:22 PM, Mark Mieczkowski wrote:

> Scott,
>
> my feature request  list. I might as well ask for the moon but if you 
> don't ask....
>
> 1. POSE hotsync support for debugging and testing

This is a POSE issue and one we have no plans on addressing.

> 2. Stationary that works.
> 3. project stationary that gives more than the bare C API entry 
> points. how about one for the Generic conduit framework and one for a 
> as yet to be determined mac based framework. see item 6.

I'm not sure we're going to do a stationery that has some sort of 
wizard for creating conduits; we don't have the resources to do this. 
We do plan on providing sample MachO conduits compiled in XCode.

> 4. I'd like to use xCode. Codewarrior for mac looks just about dead. 
> The writing is on the wall.

I believe that we will have this pretty early on.

> 5. I don't think I need to tell you this,  but I'll say it anyway, 
> support codewarrior, 8.3 +. There is simply no reason to set minimum 
> requirement to 9.x
>

We will support the current CDK which runs fine on CodeWarrior 8.3.

> 6. A working, robust Conduit Framework. Notice that I did not say 
> Generic conduit framework. The CDK 4.0.3 Generic conduit framework is 
> quite buggy, overly complicated,  and not very cleanly written. You 
> have to understand too much about the guts of it to work with it. I 
> think it is more marketing than substance. Windows has the MFC based 
> framework, could we have a cocoa conduit Framework Framework :)?
>

We do plan on having an Objective C Framework so that you can develop 
using Objective C. As for a replacement of the Generic conduit 
framework or a conduit framework, we encourage other developers to 
develop to our APIs. There is nothing stopping you from developing a 
conduit framework; unfortunately we don't have the resources to do this 
ourselves. (If anyone is interested in doing this, please contact me 
off the list and maybe we can arrange to license it.)

> 7. Backward compatibility with this mac cocoa framework so it can be 
> used with the the Palm Hotsync Manager. I've toyed around with this 
> bridge idea myself so I'm pretty sure it can be done. The Mac OS will 
> hide the implementation details so as long as the dlls are bundles. 
> This would require a Shared Lib bundle from palm for the API (as 
> opposed to a static library) and some glue to load and manage the 
> entry points to this shared library. A pass through CFM conduit to 
> explicitly load the Mach 0 dll and provide CFM entry points. I guess 
> you would also need an abstraction layer to hide who is making the 
> connection to the palm (Missing Sync or Conduit Manager/Hotsync 
> Manager)
>

We have no plans on doing this (no incentive). Our application will 
handle CFM conduits as well as MachO conduits. However, the MachO 
conduits will not be compatible with HotSync as HotSync doesn't support 
it.

>  The only difficulty I can see with this scheme is that the PROGRESSFN 
> callback could be tricky and CSyncProperties::m_UserDirFSSpec will 
> have to be handled. I guess the pass through CFM conduit would have to 
> mediate those as well. Well, since I'm starting to ramble, I'll leave 
> my wish list at that.
>
>


I realize that all of this isn't clear, yet, but we're still developing 
and one of our most important goals is compatibility with existing 
conduits, so that's where we're been spending our time.

--
Scott Gruby
Lead Engineer
Mark/Space, Inc.
<mailto:sgruby at markspace.com>
<http://www.markspace.com/>