Apropos of nothing:
https://plus.google.com/112678702228...ts/eVeouesvaVX

I thought it was worth reading; maybe you will, too.

--
frosty

On 10/12/2011 03:15 PM, frosty wrote:
What a great read! Thanks for the link, Frosty.
--
Cheers, SDM -- a 21st Century Schizoid Man
Systems Theory project website: http://systemstheory.net
find us on MySpace, GarageBand, Reverb Nation, Last FM, CDBaby
free MP3s of Systems Theory, Mike Dickson & Greg Amov music at
http://mikedickson.org.uk

On 10/12/2011 4:15 PM, frosty wrote:

Thanks for the reference!

On 10/15/11 4:05 PM, Bill Cooke wrote:
You are most welcome.

My favorite part: not just "Google+ sucks" but
why/how Google+ sucks.

--
frosty

On 10/16/2011 8:55 AM, frosty wrote:
accessible to anyone for any reason, it is the fault of the software or
of the messaging of the idea." I was raised on the dogma of
Requirements Analysis - determine clearly what folks expect, so you can
prove you are finished. Here the author denies the goal of being
finished, and shifts from a goal of "finished product" (good enough for
final contract payment) to a goal of "accessible platform" (good enough
for someone else to help meet a new requirement). Fascinating -
problems become meta-problems. Where in our education do we learn (and
teach) solving meta-problems? Do today's mv clientele know they want a
platform rather than a finished solution? ... and so on. There's a
lot to discuss!

Note that the blog was originally posted by Steve Yegge, then reposted
by Rip Rowan.

I've posted notes in my Google+ page about why I think the G+ API has
been an inadequate afterthought which prevents G+ from competing with
Facebook. This blog explains Why that's the case and it's refreshing
to get a bit of confirmation. It also dove-tails with commentary here
in CDP about how people use MV as a platform or as a product.


Quotes from the article:
For the last decade+ I have been saying it's just as wrong for MV DBMS
providers to build in many tools for the exact same reasons. Make the
platform extensible for others to build in tools, don't try to build
in everything - you're going to get it wrong most of the time, and
sabotage the evolution of aftermarkets which help platforms to thrive.

Continuing ... The same goes for MV apps. Don't try to build in every
feature that you think someone is going to want. Create interfaces
into your system that allow end-users to plug in their own extensions.
Encourage them to build into your system. Train them to use BASIC, to
work with the platform, and to make use of the after-market tools that
are available for advanced development so that they get the same
experience with your app as they do with all of your competitors'.

Apply that to the MV market.

Ibid for MV.

T

On 10/16/2011 6:23 PM, Tony Gravagno wrote:
...

.... Let's look at this.

I'm one who hasn't done this, so I have no model. In contemplating how
to study it, in an eigenexperiment I'm taking a sample database
(literally, like QM's or Universe's) and building a platform around it.
The idea is only http access to our core. I start with essentially a
void app, just whatever the data most simply implies, which seems to be
minimal defense for the integrity of the db and reasonable references to
the db. So, (without any security concerns/facilities), for GETs we
offer request field validation. For PUTs we provide code for field
validation, item coherence, item integrity (whatever that may be), db
coherence, and db referential integrity. For DELETEs - db coherence /
integrity functionality. For POSTs - functionality similar to that for
PUTs.

Granted that is minimal, but is it sufficient to start a platform?

This question is triggered by your "train them to use BASIC...". I
think the biggest reason we have for not building platforms is, not a
lack of adventurous spirit, but the idea of inviting someone to belly up
in our private stuff. With an adequate platform, can a "third-party"
can build the exoskeleton outside the mv box, never using BASIC. How
would you manage a platform with third-parties (neo-competitors) inside
the mv box, contributing BASIC (and, uh, proc?)? That implies a tighter
binding than is manageable, no?

What is the relationship of the data structures added by a new app in
extending this platform? Can it be isolated so BASIC code support would
be OK, allowing no backdoor / inter-processor access to the platform
bases? Can the new app data be proprietary to "them", and how would you
maintain the trust?

Can one really build an effective platform with not only the clients
being http accessed, but the core db and the extension apps be expected
to be accessed over http, rather than direct BASIC read-writes?

This is, to me, a big architectural, leap. Having taken it, the rest
seems easy. The stuff you build in-house and which stays in-house stays
central. The stuff others build goes on the outdoor processor(s).
Clearly I'm seeing this as a security issue and little more. But surely
an administrator / proprietor would see it this way, and would need full
assurance. If that argument isn't easily solved, what's the good of
dreaming of someone else's expansions to your data system you can't
dream up yourself? If that argument is readily solved, what else is in
the way of progress?

What is the architectural sketch for an mv platform?

-- Bill

On 10/17/2011 2:34 PM, Bill Cooke wrote:

Bill, I would have a problem responding to each of your notes in
context so I'll try to provide an adequate response up here.

Let's define a few aspects of "extensibility".
The United States Constitution is "extensible" in that the founding
fathers knew that they needed to define mechanisms in the document for
how the document itself could be changed. Linux is popular in part
because it can be extended through the source - and lack of such a
feature is exactly what has crippled Microsoft for over a decade,
though they're crawling out of the pit slowly. Useful software today
must have an API or it's not considered viable by modern
developer/purchasers. Steve said something similar: "A product is
useless without a platform, or more precisely and accurately, a
platform-less product will always be replaced by an equivalent
platform-ized product." Twitter has an API, as does Facebook, Amazon
services, Google services, and thousands of others. Content
Management Systems (CMS) like Drupal and Joomla have hundreds of
plugin modules, as do Forums, E-Commerce Shopping carts, and other
popular FOSS. The API is the mechanism which allows the software to
get a life outside of the confines of the original developers' minds.
MS Office allows plugins as do browsers and other familiar software -
MS SharePoint is an entire framework based on extensibility. There is
a Design Pattern described by the GoF in 1994 called Dependency
Injection (IIRC) which described how to do such things. In short, the
world abounds with information about how and why software should allow
others to connect into it - but MV people in large part have no idea
what this concept is, let alone how to implement it.

It doesn't matter what language or DBMS is being used. MV
applications and others can allow for plugins through the use of
Callbacks (thus my note about teaching BASIC). These days a similar
concept known as "webhooks" has been gaining popularity.

So, to implement this in BASIC you could do something like this:

* Prepare to do something interesting here.
* Now invoke a Callback
CALL CB.BEFORE.EVENT1
* Now do the interesting thing.
* Now callback again
CALL CB.AFTER.EVENT1

You just provide a SUB/RETURN skeleton for that code. Someone else
can plugin their handler if they want to invoke functionality around
your own.

So that's all in BASIC. DBMS providers can, but usually don't,
include hooks like that too. Though that's sort of what a Trigger is.
You guys use these things all the time.

Outside of MV the idea is to expose parts of your app as black-box
engines. Accept parameters for a new customer, a new order, a payment
against an order, or an A/R inquiry. You don't need a UI for that, so
abstract the CUI from the rules, have the CUI invoke the rules
separately (see my recent blogs on this topic) and then add a web
service that invokes the rules. Now end-users can create their own
GUI, whether with a browser, a mobile device, or some other mechanism.
The point here is that we as (application) developers can't imagine
all of the UI's that some end-user will want - and we'll get it wrong
most of the time if we try to please everyone with a one-size fits-all
solution.

MV developers can then plug into their own APIs in the absence of
end-user or third-party initiative. For example, if you create an API
that allows external sync of customer contacts with "some outside
source", then you can create a plugin for Google Contacts, Outlook,
Goldmine, or any other product where you see value. If you as a
developer don't create the direct interface, don't worry about it,
someone else might, adding value to your platform. You can then
advertise features which you don't even need to support, thus
increasing the "size" and scope of your offering for new audiences.

This is something the MV DBMS vendors simply don't "get" - and they
pass on that lack of understanding throughout the channel.

Combine the BASIC hooks above with "webhooks" that I mentioned.
Imagine actions in BASIC apps invoking web services "somewhere in the
cloud" which do things as an integral part of an application. For
example, when generating an estimate someone might want to call a
vendor's web service to get current part pricing. You don't need to
build that into your app, but with a hook you can allow end-users to
implement this if they wish. That capability adds value to your app!

So, as far as architecture, I've described two methods of
extensibility, accessible to MV developers right now, as well as to
developers of any other language or platform. The implementation
doesn't matter. But now as a "platform" developer, you need to make
sure that the core is solid - no aborts, no undefined parameters, no
obviously missing functionality that people will request on day 1.

Any help?

T

On 10/17/11 5:18 PM, Tony Gravagno wrote:
An added benefit of this API approach is the ability to
test each endpoint whenever you make a change to the
code.

Some very nice tools out there for this, e.g. RSpec.

--
frosty