FP/DOS 2.6 -> vfp9 report conversion
George Smith
(sp1). These were all written for a 132 column fixed width printer
driver using a Courier font at 16.7cpi
Transporter converts all the fonts to MS Sans Serif 8 spaced such that
I need to set the page layout to legal landscape to get it all on
screen. The text doesn't look wrong and it doesn't look big, but it is
overall about twice as wide as it should be.
Is it possible to get transporter to do a better job at this or am I
stuck with manually doing a search/replace on a smaller font and then
reformatting them all?
Thanks
George Smith
Albert D. Kallal
"George Smith" <grsass...@gmail.com> wrote in message
news:678787e4-1a23-4abe...@x5g2000prf.googlegroups.com...
> Sorry, wrong group!!
That ok, in fact I do have both FoxPro 2.0 and FoxPro 9.0 on this machine as
a type......
I also have jBase, and Pick AP DOS, and Linux ap pro and...
And, lets see, sql server, and SharePoint...and even access 2010.....
Over the years, I used FoxPro, but now of much slid over to ms-access. It
kind of strange, but often one has to "pick" a wagon to hitch on to (pun
intended!).
I found over the years that I was doing less and less FoxPro work, and more
and more ms-access work.
The same occurred for my pick work, there just not much to be had in my city
anymore.
In fact I have moved a good deal of my clients from pick based systems to
ms-access systems. I could have chosen FoxPro, but ms-access simply was an
more popular choice. With free editions of sql server + the ability to
distribute a free runtime edition of ms-access, then there is ZERO licensing
fees for when I distribute my applications.
Microsoft has announced there will be no new editions of FoxPro. However,
the big news for access 2010 is that it can now create web sites and the
resulting application will run in a standard browser (ie8, FireFox etc.).
Here is a video of an access application I wrote and note how at the 1/2 way
point I switch to running the application 100% in a browser...it is VERY
cool. the results are browser neutral (no activeX or silverlight required)
http://www.youtube.com/watch?v=AU4mH0jPntI
The new version of ms-access makes web reports and building of web forms so
easy that anyone who can use the wizards in ms-access can now build web
based systems...
I curious, but are there any RAD tools for d3/tiger that allow web building?
What do most people use here?
I suspect the server platform is going to be LAMP, but what is used for
things like web reports, and building web forms? Is there a nice RAD report
writer for the web? I just not been keeping up as to the goings on in pick
land.
Do folks here now use a particular "standard" set of tools for web
development, or are tools chosen on a case by case (client by client)
bases? - I suspect there is TONS of development choices here due to d3 quite
much now running on Linux these days, but I curious is there is a particular
language or set of tools that most of the pick community has adopted for web
development?
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOO...@msn.com
Tony Gravagno
>Microsoft has announced there will be no new editions of FoxPro. However,
>the big news for access 2010 is that it can now create web sites and the
>resulting application will run in a standard browser (ie8, FireFox etc.).
I hope that's for single-user applications. The thought of MS Access
behind a multi-user website gives me chills.
>I curious, but are there any RAD tools for d3/tiger that allow web building?
>What do most people use here?
As I've documented in my blog a few times, these days I think the best
way to approach GUI over MV is to recognize that there are wealth of
GUI options out there and MV is just another DBMS platform to be used
with any of them. This precludes the concept of MV-based RAD/GUI
tools. Mainstream GUIs mostly connect to a back-end via web services,
with the data packaged in XML or JSON. There's no concept of a DBMS
in there. All of these tools connect the client to some back-end that
brokers requests to a DBMS of choice, and then packages responses for
the client to render. MV is as viable a choice in this environment as
MySQL, SQL Server Oracle, or any other. The MV DBMS isn't locked into
any specific development paradigm and the more developers lock their
minds into that concept the more MV looks like a proprietary and
undesirable platform.
>I suspect the server platform is going to be LAMP, but what is used for
>things like web reports, and building web forms? Is there a nice RAD report
>writer for the web? I just not been keeping up as to the goings on in pick
>land.
The hot reporting product in the market these days is Entrinsik
Informer, but it's cross-MV support is limited. MITS Reporter is nice
but I think it's plagued with confusion about BI and repositories and
other concepts that prevent it from becoming recognized as a basic
reporting tool.
Personally I'm trying to stick with mainstream tools. I'm dabbling
with Telerik Reporting, have looked at Jasper Reports, and have
considered front-ending MV with QlikView. For tools that require an
ODBC-compliant back-end it's not too tough to offload MV data into SQL
Server or MySQL for tools that are designed for those platforms. This
is just another way to prove MV can play nice with the rest of the
world, to avoid having it tossed because people think it can't.
>Do folks here now use a particular "standard" set of tools for web
>development, or are tools chosen on a case by case (client by client)
>bases?
I prefer .NET and therefore ASP.NET, but I don't lead with technology.
Before making a proposal I'll ask questions that help the client to
determine which technologies are best for them in the long run. That
might lead to FlashCONNECT, DesignBais, ASP.NET, or Flash/Flex. I
don't know anyone doing Java applet development anymore, and if they
want LAMP, they can do that, with MV replacing MySQL. For people who
insist on Linux-only development, I'm happy that Telerik RadControls
now supports Mono, which means we can develop a website with ASP.NET
and some really nice UI controls, and deploy over Linux or Mac. I
don't have any clients who have asked for this yet but it's all
possible and just waiting for someone to say they want it.
>I suspect there is TONS of development choices here due to d3 quite
>much now running on Linux these days, but I curious is there is a particular
>language or set of tools that most of the pick community has adopted for web
>development?
One main problem is always connectivity. To date, D3 has been limited
primarily to comms through Telnet and sockets. An interface through a
wrapper like d3tcl is also possible but then you'd have to work out a
pooling mechanism. Frankly, the problem isn't technology, it's market
demand. Without anyone willing to pay for real/better interfaces, no
one in this market is stepping up to offer them. Compare this with
the rest of the world where there are a hundred interfaces to
platforms like Twitter or Facebook, simply because people actually
want to use the platform.
For reference, D3v9 has a basic .NET interface and the exact same API
supports Java as well. This will facilitate cross-platform
development similar to that which U2 developers enjoy today. However,
the problem is still with demand for projects which make use of the
interfaces. D3 has had many connectivity methods over the years but
people simply don't use them. I fear the new connectivity won't do
anything to improve the vision of MV-oriented developers.
Personally, [AD alert] my platform of choice is mv.NET, especially
with the new Solution Objects library. This allows me to create thick
or thin applications (plus web services or interfaces with other
databases) for almost any MV environment, and to deliver an SDK to
other developers so that they can code against the MV platform without
knowing a single thing about MV. This is sure to help MV developers
expand their options ... if only a solid marketing effort can be
created to make them aware of their options using these new features.
It all takes time and needs to be balanced with anticipated demand ...
such things are sometimes "chicken and egg" propositions.
Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
Nebula R&D sells mv.NET and other Pick/MultiValue products
worldwide, and provides related development services
remove.pleaseNebula-RnD.com/blog
Visit PickWiki.com! Contribute!
http://Twitter.com/TonyGravagno
Albert D. Kallal
message news:crnaj5dd79hlpmu7f...@4ax.com...
> "Albert D. Kallal" wrote:
>
>>Microsoft has announced there will be no new editions of FoxPro. However,
>>the big news for access 2010 is that it can now create web sites and the
>>resulting application will run in a standard browser (ie8, FireFox etc.).
>
> I hope that's for single-user applications. The thought of MS Access
> behind a multi-user website gives me chills.
>
Actually as mentioned, the common set up these days is to use SQL server for
the database.
Keep in mind when you publish access databases to the web, you not using
JET, but in fact are using SharePoint lists and what is now called "access
web services".
So when you publish an access application to the web (and, it is one click
option), the resulting web application is browser neutral. The resulting web
application is based on Microsoft's CLOUD computing architecture. This means
the resulting access application is extremely scalable (we're talking about
what we called horizontal scalability). You can scale out to thousands of
users. In fact, the whole architectures based on the cloud computing
initiative. All this stuff is based on the same architecture that the online
versions of the SharePoint services. They scale very well indeed to many
users.
I suppose I should probably point out that it's often people confuse MS
access with that of the database system. We don't call .net or vb6 or c++
the database system. So, MS access is not the database. MS access is the
development system that allows you to build a web site, or a desktop
application (the new version allows you to build both desktop and web
applications). However the ability of MS access to develop forms or build
reports and allows you to write code has LITTLE to do with the choice of the
database system.
For desktop only applications, you can choose the JET database engine, or
now what is called ACE (in fact, the new ACE engine has multi value
capability, and also has database triggers). You can also build applications
in MS access that are 100% native oleDB connections to sql server.
So, you failing to realize the difference between a database engine, and
that of a development system like MS access. ms-access is most certainly an
different concept then that of an database engine. We would not call MS
access a database system no more than we can call vb.net a database system.
You are not forced to use the jet/ace data engine when you build
applications with MS access. The scalability of the application is going to
be based on what database you are going to use with ms access, not MS access
itself.
As mentioned, this whole issue gets even more confusing with access 2010 due
to web site creation ability. If you look at that video posted, note how I
switched the application over to running 100% in a browser based
environment. That browser + web part is based on the new "access web
services". That services runs on SharePoint and will also be available as an
online edition. That's why I'm stating these resulting applications are very
large horizontally scalable (by horizontal, we mean large numbers of users,
not necessarily large amounts of data)
> Mainstream GUIs mostly connect to a back-end via web services,
> with the data packaged in XML or JSON. There's no concept of a DBMS
> in there.
It's kind of interesting the way ms-access works when you publish the
applications to the web. ms-access now communicates with the Server side
with a new set of web services. You can actually continue to use the desktop
version of the application and run it on the rich desktop after it been
published. This published application has built in replication. This means
is that you can run your laptop and run the application in offline mode.
When you get back to civilization with a decent web/internet connection,
it'll will start synchronizing all your data for you. And, it can do this
automatically. In other words I can provide my clients with offline mode
applications. And, not only that, you can also use the web parts of the
application with any standard browser.
>
> The hot reporting product in the market these days is Entrinsik
> Informer, but it's cross-MV support is limited.
I should probably point out that when you publish an access application, the
report part is actually based on SQL server reporting services - the result
is a very nice reporting system for the web, but with the ease of ms-access.
I'm still so spoiled with MS access on the desktop client, as it's always
been one of the best report writers I ever used, and even better is on the
desktop, those reports are permitted to have VBA code in the report...
> which means we can develop a website with ASP.NET
> and some really nice UI controls, and deploy over Linux or Mac. I
The resulting access applications are browser neutral, I've tested the
resulting web application running in FireFox on a Linux box (Ubuntu). The
ms-access forms rendered just perfect.
Anyway, it's not a big deal, but I think you're confusing the concept of the
jet database engine, with that of the development platform called MS access.
Often people confuse the two, and often people use the term interchangeably.
It is important to point out that often people don't understand MS access,
or have limited knowledge of the product. Since office 2000, access has
shipped with an desktop version SQL server. Today, most just use free SQL
server express in place of the older MSDE that shipped with office for many
years now.
So, MS access is not the database here and it never was. MS-access is simply
a development tool, and you THEN choose the database engine, be it ACE,
MySql, sql-server, or now SharePoint for the web based applications.
Tony Gravagno
[major snip]
>So, MS access is not the database here and it never was. MS-access is simply
>a development tool, and you THEN choose the database engine, be it ACE,
>MySql, sql-server, or now SharePoint for the web based applications.
After reading that a dozen times or so, I think it's starting to sink
in. ;)
Actually I have used the MS Access application against different
databases, but the common correlation is Access=JET=database=MDB=Ouch.
Yes, knowing nothing about what Microsoft is doing in that area, I
misunderstood. Thanks for the clarification.
BTW, when I said 'deploy over Linux and Mac', I wasn't talking about
browsers. ASP.NET has supported all popular browsers for about 10
years. I was talking about deploying ASP.NET over Linux or Mac
servers, with any browser hitting those servers with no Windows
required anywhere in the topology. Most people have it in their minds
that ASP.NET means Windows-only servers, one or two languages, and
maybe even IE-only. That's just all wrong.
T
Albert D. Kallal
>
> Actually I have used the MS Access application against different
> databases, but the common correlation is Access=JET=database=MDB=Ouch.
It's a fair point and one of those kind of misconceptions. To be really fair
even some of the Microsoft documentation on their own website often fails to
make that distinguishing between the two products (JET and ms-access). I
spend a lot of time and then MS newsgroups helping people, and this issue
often comes up. For the most part distinguishing between JET (now called
ACE) and ms-access is not a big deal most of the time. However when talking
about issues of scalability, then it becomes a significantly important
issue.
> I was talking about deploying ASP.NET over Linux or Mac
> servers
> Most people have it in their minds
> that ASP.NET means Windows-only servers, one or two languages, and
> maybe even IE-only. That's just all wrong.
I've been aware for some time that asp.net pages can be run on Linux servers
(via mono). However the problematic areas were drivers for database systems.
I not kept up in this area, but I just have to assume that drivers
(providers) for mySql, or Oracle (or even perhaps pick) have improved to the
point that it become practical to deploy asp.net in real world business
applications on Linux (I been told that drivers and providers make this not
so practical - but, these things change over time).
I guess at the end of the day this all comes down to how much you want a tie
yourself and your project into an particular database server/system.
Giving up MS sql server with .net means a significant number of features of
the server such as .net assemblies which SQL server can consume are not
going to be available anymore.
This "problem" is pretty much the same with oracle, mySql, pick, or MS SQL
server. In most cases and in most applications for businesses, you'll wind
up using some particular features of that particular database system. As a
result, I'm not really convinced it's feasible nor technically possible to
assume that if you write an application around asp.net, you have a seamless
pathway to running that system and application on a Linux server. I suspect
the resulting application might be cross platform if you stick to using
MySql from day 1. However, I'm not even sure drivers and DB providers are
available for using a asp.net and Oracle, or even for Pick, or even
communicating with another server running Sql server on that Linux box.
I think there's also few and far between Internet providers that have mono
support for Linux hosted web sites.
So while I think asp.net pages can be published to an Linux server, once you
get down into the nitty gritty of an actual business application, I'm not so
convinced that's quite practical to do this as of yet. I suspect that while
asp.net pages can be well deployed to Linux boxes, I am not sure of
advantages in using asp.net. I think using the common LAMP development tools
are a better choice and thus I still think one is better served by using
tools with a longer term history for the respective platform.
At the end of the day, the industry is moving towards me being able to
develop an application using a given technology, and then the resulting
"package" is then deployed to a particular platform. In other words the idea
here is that you build an application, and then can sell and deploy it just
like any other application running on the desktop, but now it's running for
platform in the cloud.
The apple Iphone is so very popular is because they created a marketplace
for developers to fuel so many interesting applications. If you look at
where the cloud providers are going, or even the new version of access 2010,
the idea is that you build an application using a set of tools, and then you
are able to publish that application as an single application in which the
server consumes it and puts together the pieces needed (such as needing SQL
server, perhaps some server reporting services, etc).
The concept of scalability, and the ability to have more than one customer
purchasing a resulting application is a critical concept here. We see this
"packaged" concept as initiatives being adopted by all of the major cloud
vendors. The apple iPhone shows that fueling developers and a single
platform into which to deploy to, you thus create a marketplace that fuels
more software. Its software that drives any particular platform today.
I think MV systems such as pick would have died in the marketplace a long
time ago if not for so many GREAT line of business applications that live on
today.
So, its software that drives the adoption and use of any platform. Remember
these new cloud systems will allow you to pick your database system, your
payment processing system, your reporting system. The new development
systems thus allow you to take all of these parts put them together in one
coherent software package that you can sell and deploy a into that
particular clout operating system.
The march towards having cloud systems into which we deploy software
packages is really where the future of our industry lies.
Furthermore if you don't want to publish to a cloud system, then you be
publishing to a local server on premises - but I firmly believe the concept
of a package software system that allocates all the services needed in one
package is the future of our industry.
RJ
is that whatever you know well you do well. I suspect but can't say for
sure just yet that the best all around combination for the types of
applications that most of us have done in the past is VB.NET using VB 2010.
I'm thinking distribution applications mainly with general accounting
included. We don't generally do device drivers or compilers so getting
closer to the iron has little value. There is a high overhead with the dot
net and the cloud that can be avoided with old fashioned Pick but there
appears to be enough value associated with the overhead to justify the cost.
And the iron is fast and cheap. The speed of the backbone - or lack of
speed - has become a problem but there is relief in sight when and if the
military let go of some of their closely held capability.
BobJ
"Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in message
news:vhDZm.57593$ZF3....@newsfe13.iad...
Albert D. Kallal
news:TiJZm.65389$DC2....@newsfe02.iad...
Thnaks you knidly for the comments.
> I'm thinking distribution applications mainly with general accounting
> included.
I can't stress how important the concept of cloud computing is. Cloud
computing is a terribly overused buzzword, but what significantly important
in most of the cloud offerings from Amazon, Microsoft's Auzure, or Google
virtually all of them are moving towards an system in which you are building
a packaged software solution.
For all successful systems you find three main components:
1 - the operating system
2 - developers who create software for the operating system
3 - consumers who are willing to pay for that software
(I was going to attempt to draw a triangle, but the above will suffice)
When you see above, the famous "developers developers developers" Steve
Ballmer was talking about, he was talking about ONE of the 3 pillers of
successful software platforms.
You need all three above components. The iPhone, or windows marketplace
shows you need developers. The MOST IMPORTANT part is those developers is
the need to make money. I should rather state that oracle's also figured
this out quite well. Without developers being able to make money, you won't
have a steady flow of new developers moving in to that marketplace and
adopting a particular platform such as oracle or the iPhone, or windows.
Developers write software for the windows platform because there is an
marketplace in which consumers are willing to purchase that software.
Without that willingness to purchase software you don't fuel new innovation,
or fuel an supply of new products and bring in developers.
People so often asked why the linux desktop hasn't done so well. Linux as a
desktop os is a perfectly capable operating system able to run you're e-mail
and word processing (I have Ubuntu running for testing things, and it is
nice). In fact there is a free editon of office that allows you to use excel
and word and most of the office applications - You don't have to purchase
anything at all.
So there's little if any reason for consumers not to adopt linux. However
the main reason why consumers don't adopt linux is because there's not all
kinds of software being built and sold for the desktop on linux. There also
additional challenges of packaging software and it typically not possible
for different flavors of Linux. However, the real problem here is that Linux
users tend to be users that don't purchase any packaged software for their
desktop. As a result as a software vendor who wants to build packaged
solutions for customers that never tend to purchase (or pay) software in the
first place? In other words the users are getting ("used to") most of their
software for free, and as a result you don't see a really great marketplace
for us software vendors to sell our software into the linux desktop.
Contrast the above to the wild success of the iPhone marketplace. Almost
every developer I talked to is trying to stampede and jump into the iPhone
marketpalce. I guess when some young kid starts making $3,000 a day selling
an application that makes funny fart sounds on the iPhone, you rather
quickly begin to realize what it is that drives so much of the iPhones
success. In the mobile marketplace, Apple is now very much like Microsoft on
the desktop. Competitors can come out with just as good as an smartphone as
Apple, but they don't have 100,000 applications for consumers to choose
from. Now I could argue that not every one of those hundred thousand
applications is great, but they're simply so far ahead of the competition,
they've pretty much sealed up that marketplace to themselves. No question it
was a great iPhone hardware that allowed Apple to get their foot in the
door, but now it's the huge amount of software that really drives success of
the iPhone. However what's even more important is that developers can make
money by selling into that marketplace, and thus you see an massive amount
of software continuing to be created for that iPhone platform.
I remember how successful the Pick "hits" book was at one time. (it was
huge). My point here is that developers could easily make money by moving
into the iPhone marketplace or even the pick marketplace at one time (and so
they did).
You don't see a lot of vendors building a lot of new software for the pick
marketplace. This is not so much becuase picks not is not a good system. The
reason why you don't see a lot of good NEW software is because as a vendor I
can't sell into the pick marketplace and make the kind of money I can by
selling into the windows market place.
Over the years I moved my appliaons out of pick and into windows. One of the
key components and goals was I wanted to sell my software to people living
in different cities. Having a consistent platform in which I could design
and package an software solution, and then have it simply deployed to
clients everywhere was the gold ticket that was important to me. As a result
I now have customers that I've never met in person, and yet I support them
and deploy my software onto their operating system (windows). I also use a
windows installer for those applications.
So I just wanted to point out the important concept of these marketplaces,
and that's the key Concept as a vendor to look for. You want to choose an
operating system "platform" into which one's work can be sold into.
For me personally my decision as to where my applications are moving to is
now SharePoint. In other words, whatever you do, do choose an standardized
platform into which you can SELL your software into.
Whichever platform a vendor chooses, that choice should have both cloud
based and local server based deployment options. There's many reasons for
the success of sharepoint, and is the fastest product to reach a billion
dollars in sales for Microsoft. However what's most interesting, is once
again we're seeing the rising of a marketplace for vendors to sell software
into the sharepoint marketplace, and that is the critical concept I'm trying
to convey here, regardless of what platform anyone here chooses to sell
their software into.
Tony Gravagno
necessarily be worried about consuming services in the cloud, but that
they should be thinking about taking their great apps and making them
deployable in the cloud for all those people who want to make use of
such apps.
RE: Databases, ASP.NET, Linux, etc: Proper development separates tiers
but a lot of your comments implied usage of the database was
intertwined with the UI. There is no "ASP.NET with SQL Server".
There is an ASP.NET application that uses a SQL Server provider.
Switch the provider to MySQL or MV and the same application should be
able to function in any environment. No, it's not a slam/dunk but the
code is much more versatile with a small amount of forward thinking.
RE: Running apps in hosted environments: I've used a lot of hosted
services and wouldn't trust any of them for a real application the way
we run MV multi-user apps. You don't run a real business on a
$8/month shared server. But from anywhere from $15 to $100/month you
can get excellent root-access hosted or private servers from which you
can run anything you need.
RE: iPhone, monetization, and the failure of the Linux desktop: I
think you've hit it right on. With no incentive there is no supply,
and with no supply there is no demand. When consumers cross the line
from "it must be free of charge" to "I'll pay a buck for it", then
developers will jump to catch all of those dollar bills falling from
the skies. When that happens, software quality, diversity, an
innovation all improve as well.
>You don't see a lot of vendors building a lot of new software for the pick
>marketplace. This is not so much becuase picks not is not a good system. The
>reason why you don't see a lot of good NEW software is because as a vendor I
>can't sell into the pick marketplace and make the kind of money I can by
>selling into the windows market place.
Bingo: I and many colleagues have lamented about the same experience.
To survive, we need to redirect our efforts away from the MV space,
and that just perpetuates the lack of innovation seen in this market.
If MV developers were more like everyone else we'd all do a lot
better. That means paying a buck for something of value rather than
insisting on everything being free. That means buying tools now to
sell new software tomorrow, rather than waiting forever for the DBMS
vendors to build in something that doesn't belong in a database. That
means using tools (free or otherwise) created to suit specific needs,
rather than insisting on everything being in BASIC.
About sharepoint etc, I think this is where guys like you and I, and
other developers diverge: Most MV people are not tool builders,
they're application developers. As such they need to sell software to
end-users over platforms that appeal to the sensibilities of the their
target market. But Pick people tend to think end-users don't care
about the platform (it's about the applications and not the database).
While I agree to a great extent, some flexibility is required. You
don't need to port into sharepoint or these other buzzwords, but at
least acknowledge the buzzwords that people have already bought into
and try to offer some sort of integration. You don't need to port to
SQL Server, but you should be able to exchange data with it. You
don't need to deploy in the cloud, but you should expose some useful
functionality through web services. You don't need to have a full
GUI, but you do need to provide some management reports or a dashboard
through a GUI. It's not all or nothing, it's adding features that
appeal to a more diverse audience.
Whatevah... Broken record...
T
Albert D. Kallal
Great comments Tony..thanks......
>There is no "ASP.NET with SQL Server".
There is an ASP.NET application that uses a SQL Server provider.
Sorry, I really meant to say that sql server now has the ability to consume
what is called an .net assembly. That means sql server can consume CLR (net
code). To be really honest, coming from pick, I always thought that t-sql
was a poor language. I always wished that the sql server could consume and
run a decent programming language much like we had in pick land (mv-basic is
a far better language then t-sql for example).
>But Pick people tend to think end-users don't care
about the platform (it's about the applications and not the database).
While I agree to a great extent, some flexibility is required. You
don't need to port into sharepoint or these other buzzwords,
Agreed. I'm only trying to stress that you NEED to adopt some software
stack, be it LAMP. The key concept here is some standardized platform in
which you can deploy your software into.
The problem with so many customer LAMP installations they are so customized
you can't make any assumption about what database system they're using
(MySql, or Postgress??). You can't assume what kind of reporting system they
are using. You don't know what email system. As a result it's near
impossible to build up a marketplace today with this kind of fragmentation
in terms of the installation and system that most customers have.
I not trying to sell you on "xxx" system here, but just pointing out that
SharePoint is an marketplaces and STANDARD system into which I can vend
software into. So, that's simply my choice. I can rest assured that
customers running SharePoint will be able to consume and run my software
package with an easy install.
So it's the marketplace and the repeat sales concept that I was stressing
here.
You can't imagine how much I loved the pick marketplace in the 1980's. I
remember working in one machine a with customer using DataMedia. Another one
was on Ultimate, and another was starting to run an 286 box with pick from
pick systems. For ALL of these customers I knew that I had a particular word
processor (JET/UltiWord), I had a particular report writer, and I had a
common programming language and even a common scripting batch system
(procs). I was ASSURED that this code would run on all of these systems.
Sure there was often a few minor changes between different vendors, but for
the most part the concept here was a standardized marketplace that I knew I
could vend my software applications into.
I find that most customers in Linux environments don't have this level of
standardization. You often have to introduce some new report writer system,
or have the customer a purchase additional server or certain applications
that they don't necessarily have. Too many different databases! So, it hard
to put together a solution that works for all those vendors.
So I'm saying whatever platform you write into, you can't really get ahead
if you have ten different customers and they all have ten different
platforms. You can't effectively offer solutions to those ten customers
unless they have the SAME platform that you've written your standard
software to.
This is why it pointed out the significant efforts and resources being made
with the new cloud operating systems. We will VERY likely see the rise of
marketplaces that work very much like the iPhone marketplace in which
customers simply download and purchased applications for those cloud os
systems.
So, whatever platform you adopt you simly have to pick one. I'm adopting
SharePoint. I not adopting it because of some buzz word, but because it fits
the client base and customers I have. And, I need the ability to deploy
application's I'm building. As long as you're running the right version,
then I know what database system you have, I know what report writer you
have, I knew what web services you have.
The pick market was a great standardized platform at one time. I am finding
that SharePoint is that new system that fits my needs and it's allowing me
to move many business processes into web based solutions.
So everyone's mileage is going to vary here, but I do think it is critical
to have future plans to adopt some platform that represents an viable market
place that can result in reproducible and repeated sales...
Funny I haven't spent much time around here, but it kind of hurts to think
about how great the pick marketplace in the 80's and 90's was. I miss pick
and I miss those days...
Tony Gravagno
which I've been trying to convey here for many years: it doesn't
matter what tools or stack you use, just pick one and move forward.