filecaddy-developers

[Filecaddy-developers] Updates!

[Matthew B. <mb...@ma...>]

Woh, long time no C...VS update, eh?

As much as I love flossing my cat, the time for updates is neigh.  I've b=
een=20
working a bunch on the plugin archatecture, and have put together a spiff=
y=20
makefile and code example that should, in theory, work.  Just need to mak=
e=20
some test programs so I get a full grasp of how to do this...

I'll be posting an update to the website so people know we're still alive=
 and=20
working, as well as the plugin code example and some docs on how to write=
 a=20
plugin that does spiffy things.  Any input on how to do the plugin system=
=20
would be really handy about now.  What follows are some preliminary ideas=
=2E..

Plugins will have one main function exported - PlugInMain - which gets pa=
ssed=20
a pointer to the following structure:

typedef struct {
=09void *globals;=09=09// pointer to plugin-allocated space
=09PlugCmd type;=09=09// type of event being passed

=09typedef union {
=09=09typedef struct {
=09=09=09Boolean menuItem;
=09=09=09Boolean vfsHandler;
=09=09} startup;

=09=09// ...
=09} data;
} Plug_ParamBlock;
typedef Plug_ParamBlock* Plug_ParamBlockPtr;

Yes, I know the above will not compile.  Call it P-code, if you will.   =20
PlugCmd is of the following enumeration (hopefully the tabs don't get too=
=20
badly garbled by your e-mail client):

typedef enum {
  cmdStartup,=09=09=09=09=09// plugin is loaded and first run
  cmdShutdown,=09=09=09=09// plugin is run for the last time
  cmdRestart,=09=09=09=09=09// plugin restarted by user
  cmdGetInfo,=09=09=09=09=09// hack style about dialog
  cmdSetup,=09=09=09=09=09// hack style configuration dialog

  cmdChangeVolume,=09=09=09// user requested new volume
  cmdChangeDirectory,=09=09=09// user tapped a directory entry
  cmdMenuTap,=09=09=09=09// user chose plugin from the popup
  cmdFileCopy,=09=09=09=09=09// user requesting to copy file(s)
  cmdFileMove,=09=09=09=09=09// user requesting to move file(s)
  cmdDelete,=09=09=09=09=09// user requesting to delete file

  // the following are used to emulate a new VFS mount...
  cmdVFSDirCreate,=09=09=09=09// create directory
  cmdVFSDirEntryEnumerate,=09=09// scan directory
  cmdVFSExportDatabaseToFile,=09// copy DB to file
  cmdVFSExportDatabaseToFileCustom,=09=09// copy DB to file w/ progress
  cmdVFSExportFileToFile,=09=09// copy file to file
  cmdVFSExportFileToFileCustom,=09// copy file to file w/ progress
  cmdVFSFileClose,=09=09=09=09// close open file
  cmdVFSFileCreate,=09=09=09// create empty file
  cmdVFSFileDBInfo,=09=09=09// get palmOS database information
  cmdVFSFileDelete,=09=09=09// delete file
  cmdVFSFileEOF,=09=09=09=09// at end of open file
  cmdVFSFileGetAttributes,=09=09// get file attributes (chmod)
  cmdVFSFileGetDate, =09=09=09// get created/modified/accessed times
  cmdVFSFileOpen,=09=09=09=09// open file
  cmdVFSFileRead,=09=09=09=09// read data from file
  cmdVFSFileRename,=09=09=09// rename file
  cmdVFSFileResize,=09=09=09// resize file
  cmdVFSFileSeek,=09=09=09=09// seek in open file
  cmdVFSFileSetAttributes,=09=09// set attributes (chmod)
  cmdVFSFileSetDate,=09=09=09// set file created/modified/accessed times
  cmdVFSFileSize,=09=09=09=09// get file size
  cmdVFSFileTell,=09=09=09=09// get current location in open file
  cmdVFSFileWrite,=09=09=09=09// write data to file
  cmdVFSImportDatabaseFromFile,=09// copy file->internal database
  cmdVFSImportDatabaseFromFileCustom,=09// copy file->internal w/ progres=
s
  cmdVFSImportFileFromFile,=09=09// copy file->file
  cmdVFSImportFileFromFileCustom,=09// copy file->file w/ progress
  cmdVFSVolumeEnumerate,=09=09// find available volumes (drives)
  cmdVFSVolumeGetLabel,=09=09// get volume label
  cmdVFSVolumeInfo,=09=09=09// get volume extended information
  cmdVFSVolumeMount,=09=09=09// mount volume
  cmdVFSVolumeSetLabel,=09=09// set volume label
  cmdVFSVolumeSize,=09=09=09// get free/used space on volume (may not app=
ly)
  cmdVFSVolumeUnmount,=09=09// unmount mounted volume

  cmdPlugCustomBase =3D 0xF000=09// base point for custom functions
=09=09=09=09=09=09=09// big number =3D lots of standard functions ;)
} PlugCmd;

Possible ideas include having the VFS functions be in a seperate code res=
ource=20
and seperate enumeration, to leave space for any new "normal" command...=20
missing anything that we may need?

If I can manage to get this to work, we'll have the only truly extensible=
 file=20
manager in the Palm world... whee!

--=20
Matthew (Darkstorm) Bevan       mb...@ma...
Margin Software, NECTI.=09=09http://www.marginsoftware.com
=09Re-inventing the wheel, every time.

 - "I'd love to go out with you, but I have to floss my cat."

[Filecaddy-developers] Plugin Archatecture

[Matthew B. <mb...@ma...>]

Using the basic structure I posted before, I have managed to get a plugin=
=20
testing program (calls various functions and checks the return values) an=
d=20
the example plugin to work together.  Attached to this message (I hope th=
is=20
works ;) is a tar.gz of the code and example PRCs...

Now to merge this with FileCaddy and start the -real- work.

--=20
Matthew (Darkstorm) Bevan       mb...@ma...
Margin Software, NECTI.=09=09http://www.marginsoftware.com
=09Re-inventing the wheel, every time.

 - "I'd love to go out with you, but I have to floss my cat."

Re: [Filecaddy-developers] Updates!

[David J. K. <dke...@ko...>]

I think you're trying to do too much with the plug-in architecture. You're
trying to create an extensible file system but VFS is *already* extensible.
For example, if you want an NFS or FTP module, why wouldn't you just write
it as a filesystem module that plugs into the VFS manager so that all
applications (not just FileCaddy) can use it?

Also, the more complex the plug-in architecture, the less likely developers
will be to write plug-ins. I know that what you have so far doesn't seem all
that complicated to you, but the fact is most PalmOS developers are *not*
expert C coders and I guarantee that what you're proposing will severely
limit who can and will write plug-ins. Even the simple plug-in architecture
for FAFileMover (simple as it was) was too complicated for few developers
that I approached with it.

Unfortunately, I don't have much time for FileCaddy these days (I'm
desperately trying to find enough paid work to keep Kopsis afloat) so I'll
leave the decision of how to proceed up to you.

-- 
    - Dave Kessler
      President - Kopsis, Inc.
      http://kopsisengineering.com


On Tue, Sep 10, 2002 at 12:03:42AM +0000, Matthew Bevan wrote:
> Woh, long time no C...VS update, eh?
> 
> As much as I love flossing my cat, the time for updates is neigh.  I've been 
> working a bunch on the plugin archatecture, and have put together a spiffy 
> makefile and code example that should, in theory, work.  Just need to make 
> some test programs so I get a full grasp of how to do this...
> 
> I'll be posting an update to the website so people know we're still alive and 
> working, as well as the plugin code example and some docs on how to write a 
> plugin that does spiffy things.  Any input on how to do the plugin system 
> would be really handy about now.  What follows are some preliminary ideas...
> 
> Plugins will have one main function exported - PlugInMain - which gets passed 
> a pointer to the following structure: