Peter McMurray wrote:

The issue isn't generally with "small" code. Your code can be too
small. Such concepts are at the heart of decisions about multi-tier
architectures.

I thought I'd create a new thread to expand on this topic. I started
by posting both Part 1 and Part 2 of a blog series called "MV to the
web".
nospamNebula-RnD.com/blog/tech/mv/2011/08/mv2web1.html
nospamNebula-RnD.com/blog/tech/mv/2011/08/mv2web2.html
(copy/paste URL to your browser starting at Nebula)

I'll address Peter's quote briefly here, but expand more in Part 3 or
4 of the blog series.

In short, if your server-side code is too small and all you have is a
client and a server, then you're just going to have a chatty
application with a lot of network traffic. Since the network can be
the slowest component in the environment, your effort to make your
code small and efficient has just doomed your application to being
slow and network bound.

You can create a robust and versatile environment with judicious use
of modular (yes, "small") coding, effective state management, use of
multiple tiers, and even asynchronous processing (not related to
AJAX). I hope the blog will serve to drive discussion on these
topics.

T

On Aug 14, 9:42*am, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid>
wrote:
Tony,

I must have missed a couple of steps here .... how does having small
code size make an application any more "chatty" than talking to a
larger, monolithic piece of code?

Guess I'll have to find time to read the blog to gain this insight,
but I'm not sure it will stand anything beyond casual scrutiny

Well, I guess I don't need to publish anything on that topic. LOL

As usual, zero comments on what I do write, but lots of Q&A on what I
didn't. Whatevah...

Good stuff, Albert.
Thanks.
T

Bill, I'm glad you get the premise. Thanks. For reference, I've been
talking about API's for MV apps for years.
Google "group:comp.databases.pick tony api"

WRT meetup.com and their API, I think you'll find that most new
service-oriented websites these days offer an API - I'd go further and
say any new site like this is doomed to immediate failure without an
API. It's the expected thing these days. The wisdom of the founding
fathers of the USA was that they created a constitution that provided
for its own ammendments - because they knew they couldn't solve all
problems on their own. Similarly, most new sites these days are
"platforms", and identified as such by the presence of an API. These
sites rely on new developer communities to build around their
offering, adding value and new interfaces, whether for free or not.
Just look at Facebook, Twitter, Google, LinkedIn, and a thousand
others like them. There are even websites dedicated to the process of
creating and supporting API's for any platform. This is just the way
it's done these days. Again, I've been saying for years that the rest
of the world won't consider an offering that isn't extensible with
plugins - and yet getting most Pick people to even understand this
concept has been an almost impossible task, and even today we
occasionally fight the "plugins are evil" battle which was lost a
decade ago everywhere else. I have other unpublished articles on
creating an API for your app, and multi-language SDKs for all MV DBMS
platforms. I just lack the time (and fiscal incentives) to get them
all out. But I will do so as time permits.

You're right that transitioning from procedural code to event driven
is non-trivial, but this is exactly the process that every single
developer has gone through as they re-fit their apps for GUI. Every
product in this industry and every connectivity tool requires that the
app developer accept this paradigm shift.

But once that has been accepted, the MV app is open to any client, any
external language, any third-party tool. And as I said in the blogs,
this can be done at no cost (except for one's time) and without
learning anything new.

Thanks again for your feedback!
T

On Aug 16, 9:17*am, "Albert D. Kallal" <PleaseNOOOsPAMmkal... (AT) msn (DOT) com>
wrote:
....

And the problem with the 'round trips' are the layers the the data has
to move through to get to the Pick DB and back?

Take the extreme example of a Y/N field and some pick software that's
been around since the 70's. Of course that Y or N
character was validated right away, you'd never <submit> a page of
data on a system you couldn't easily cursor back to
correct. Then came telnet instead of RS-232 and that Y got wrapped
into an IP packet with maybe 20 bytes of IP header.
With the web that Y character is probably surrounded by all sorts of
<tags> and XML so the overhead for that character
is like what, a few hundred bytes now? Which has to make its way
through the HTTP server, that interprets the request
moves the data around to hand off to some middleware (I'm used to cgi,
but I'm oldschool) which then reformats the data again
to call/connect to a Pick process. So our little Y character has now
been copied three times on the
back end servers. And the reply gets copied back up and reformatted
three times before being sent to the clients browser, and
probably gains a coupl of hundred bytes in the process.

Now on the Pick system that Y/N field controls several other fields,
if Y a couple of text fields will be prompted in N they'll be
skipped. I guess that sort of functionality has to now be coded in the
script running in the clients browser? But if that Y response
is not valid for certain combinations that are hard to predict, I
guess you just have to suck up the round trip.

Some of the most hair pulling problems come from doing something with
software that it wasn't designed to do. Like using MS Word
as pseudo forms printing server, or Excel as database entry system.
Or using a system designed to disseminate particle physics data, for
everything.

Jeremy Thomson

Part 3 of the "MV to the web" series has been posted:
nospamNebula-RnD.com/blog/tech/mv/2011/09/mv2web3-html.html

Many of you are familiar with the material that I've covered but I
know a lot of people haven't yet quite connected all the dots. I hope
this helps with that process. For others, I'm hoping I've been able
to provide a couple tidbits that make the reading worthwhile for you
or perhaps your developer employees.

Part 3 is a bit different from its original design because Albert
provided some excellent coverage on related topics in his posting to
this thread.

Unless someone feels I've missed something significant, I don't feel
an urge to do a Part 4 on this one.

Enjoy.
T

On 9/6/2011 7:38 PM, Tony Gravagno wrote:

Your recent posting to an App Inventor forum led me to:

http://www.programmableweb.com/apis/directory/1

This is a catalog of nearly 4000 web apis! A diverse crowd, I've no
idea if any are mv apps. Some are only a day old, some five years old,
underscoring that this concept is tested technically and seems to have
been tested commercially as well. It seems attractive for "end-user"
specialist and social purposes as well as for cementing partner
relationships in commercial, special-interest, and governmental
organizations. The EPA is just concluding a contest for apps utilizing
their data bases, offering a rich design experience for extending value
from fully-amortized data systems.

http://www.epa.gov/appsfortheenvironment/

While "data-mining" has been around for years as a means of finding
riches in the detritus of production data systems, Tony is underscoring
"function-mining", unearthing functional nuggets of value to scattered
partners.

A twist on the web services of sos / saas is those (few) data systems
which are managing devices, not monitoring / manipulating / managing
data historically paper-bound systems. You know, "robots", devices
which can blow glass, paint surfaces, build by deposition, cnc routers,
.... Their digital controls are fed from somewhere, and this type of app
will be integrated into corporate systems just as interfaces have spread
from reports and screens to kiosks and phone and Tasker and surveillance
and collection apps.

This api architecture is important system engineering, and apparently
easily done effectively with mv, with a low parts count and classic mv
clarity.

Again, this blog set is important. The subject, while it could have
been presented a decade ago, is ever more important as a view of the future.

On 2011-09-08 21:26:48 -0400, Bill Cooke <bcooke (AT) cookedata (DOT) com> said:

Of course there are caveats with building products/services that hinge
upon the offerings of others. On that same website can be found a
recent article on the APIs that Google has decided to eliminate from
their offerings, or for which to start charging a fee.

http://blog.programmableweb.com/2011...d-google-apis/

Web

service APIs are essentially SaaS. By using them, you potentially tie
key aspects of your business to services over which you have no control.

Personally, I have been burned twice by SaaS. Once, when a company
abruptly discontinued their service after being bought out. Another
time I had to swallow an unexpected, significant price increase until I
was able to migrate away from the service provider.

SaaS is great for providers, but potentially risky for consumers. I'm
not suggesting one avoid consuming service APIs, but you must be very
aware of the potential risk. Many of these services are not commodity
items. It may be very difficult, or even impossible, to change service
providers if you become unhappy with the offerings upon which you've
built your solution.

--
Kevin Powick