Alan Pinstein wrote:
> This is looking really nice.... BUT:
>
> >I realize that making the link structure variably sized complicates
> >matters for
> >applications that store links, but I don't see any way around that.
>
> I agree and there is a way around it...
>
> typedef struct {
> ULong creator; // source app
> Byte userData[SOME_AMOUNT];
> } LinkDataType;
>
> With SOME_AMOUNT being fixed, maybe around 12-20 bytes.
This could work, but the struct would have to be larger than what you're
thinking. The most space that any app that I can think of offhand would need
would be a database name and a record identifier. Therefore, the struct becomes:
typedef struct {
ULong creator;
ULong record; /* could be unique id or app-defined value */
Char database[dmDBNameLength]; /* maximum db name length = 32 bytes */
} LinkDataType;
That's 40 bytes. To err on the side of caution, perhaps a few more bytes should
be added for app-defined data. I can't think of any use for the extra space right
now, but I'm sure that as soon as the protocol is finalized, someone will come up
with a good reason for more space ;-). Steuart implied a need for variable length
data, which I carried over to my suggestions. Unless he had something specific in
mind there, I have no problem with fixing the size of a link at 40 bytes (or maybe
a few more).
>
> It might not suck to have an optional API launch code such as 'choose link
> target' so that one app, to create a link, could offer a 'link object' menu
> choice, which would first list all apps which are 'linkable' then upon
> choosing one, that app would be launched with a sub-launch and show a pick
> list of items. Upon choosing the item, the original app would just plop in
> the link. It makes for a more seamless user experience.
>
This would make things more seamless for the user, but it raises a lot of
development issues. First and foremost, it means that adding 'linkability' is a
much more complicated task. Linking has to be simple enough that a sufficiently
large number of apps will implement it, or else it is of little value. This idea
could require changes to the UI of the program. If it is implemented as a
sub-launch, then the second app would have much less memory than usual, which is
quite likely to cause problems. If it is not implemented as a sub-launch, then
the id of the calling app must be stored somewhere so the second app can return to
it. The calling app would also have to save additional state so that it can
process the link.
Ben
