Re: pkg.m status and question

[Juan Pablo Carbajal]

> I'm sensitive to Mike's original argument.  The future is hard to predict, 
> and deciding today on the number, name, and type of fields that will exist 
> for all time is too difficult.  In some manner, the architecture must support 
> change.  I am agnostic as to whether that flexibility is because each struct 
> lives alone as a cell element, or because there is a modifiable "UserDefined" 
> field.

Predicting the future here has no role. the point is that you need to
define a standard for your package distribution and management system.
Goals of the standard:
1. Easy to extend (here are all your concerns about the future
covered, there is no attempt to predcit the future [1], but to be able
to adapt to it)
2. Uniform and stable. The uniformity allows us to produce code that
anybody can use for they packages (if the follow the standard). The
stability is just a desire to avoid too much maintenance

Hence, the DESC fiel should have standard (required) fiels (it has
already), and the user can add more arbitrary fields, but those will
be parsed inot a uniform field (that is always present in the program
representation of the DESC file (e.g. a structure)) which could be
called "UserDefined". Standard code will not parse that field, but the
user's functions can use it in the context of their packages.

I do not think we have a differnet opinon here, but it seems you are
opposing to something in my proposal that I cannot pin-down.

[1] It is funny that you guys are worried about the future, because in
another discussion (regarding pkg unload) you prefer to not allow the
user to unload packages at will, essentialy **assuming that in the
future there is no usecase for that** (despite that fact that a use
casewas already offered). so not prediciting the future would be to
let the user unload the way the want, and if you do not like a
particular way, just warn about it.