Well there you go, Manifold continues to push the envelope on their product. A couple folks have emailed me the news that Release 8.00 is available for sale (no demo available) on their website. I see lots of references to speed and spatial database connectivity in that press prerelease and to be honest I think that is a great thing to focus on in 2007. Tucked down low is something that might get a few ArcGIS Desktop users to add Manifold to their workflow, ESRI Geodatabase support:
Spatial DBMS support for ESRI SDE geodatabases and ESRI Personal geodatabases - Manifold can now connect to SDE (also known as “ArcGIS”) data stores using any DBMS supported by ESRI or to so-called “Personal” geodatabases, most frequently encountered within Access .mdb files. Manifold can import drawings from such geodatabases or link to drawings for read/write/edit dynamic compatibility with such linked drawings to add/delete/edit objects in such drawings, even changing their assigned projections.
Some other “highlights” that caught my eye were NVIDIA CUDA support (about time someone took advantage of video card support), Spatial DBMS support for Microsoft SQL Server 2008 Spatial and PostgreSQL, IronPython scripting (would have liked to see “regular” Python support, but this is still welcomed) and User Interface Scripting (kinda makes me think back to how folks used the old ArcView 3.x). I’m sure we’ll see some more as the Manifold users start blogging about how it all works, but this is a pretty smart upgrade for those who use Manifold. Compatibility with ESRI geodatabase is huge in my opinion as it will allow companies that have invested greatly in ArcSDE to use Manifold without having to export out to shapefiles first.
27 responses so far ↓
1
Grinder
// Aug 28, 2007 at 12:19 pm
I just spent the $50. Not bad considering ESRI wants something like $500 for my yearly fee. Does anyone know if ArcMap 10.0 will be out next year?
2
Mike Sumner
// Aug 28, 2007 at 3:16 pm
Not sure what “regular Python” is, but I first wrote a PythonScript in Manifold in 2003.
I believe it’s just a matter of having Python installed and you can run PythonScript.
3
James Fee
// Aug 28, 2007 at 3:30 pm
My experience is that IronPython isn’t Python. That said, I had no idea there was Python scripting support in Manifold. My bad.
4
Milver
// Aug 28, 2007 at 7:55 pm
Well…I never liked mdb’s that much…I’m actually getting more from file geodatabases (FGDB)…
But…please enlighten me…in order to support PGDB’s by accessing the geometry objects and even “change the projection” without an ESRI API how do you decode the binary object?
If the format is not open (like shapefile) wouldn’t someone that cracked it and profits from it be under siege from ESRI?
5
Mike Sumner
// Aug 28, 2007 at 8:05 pm
See the section “Connecting to ESRI ArcSDE, ArcGIS and Personal Geodatabases” in the manual for discussion.
http://demo.manifold.net/doc/spatial_dbms.htm
6
Milver
// Aug 28, 2007 at 10:09 pm
Mike…interesting documentation…especially the “tone” of it
…it definitely looks like a product to try. However I’m still in darkness. From the documentation:
7
Jonathan Hartley
// Aug 29, 2007 at 4:11 am
For the record, IronPython is a variant of regular or ‘C’ Python which allows you to use Microsoft .NET class libraries. One compelling reason to want to do this (which I do in my current job) is to use the System.Windows.Forms classes to create a snappy native GUI on Windows from within your Python application.
It’s as simple as running a couple of IronPython specific imports at the start of your code, then you can just go:
f = System.Windows.Forms.Form
f.Show()
IronPython has very good compatability with regular Python. It’s not a 100% drop-in replacement, but in practice it makes absolutely zero difference in your day to day coding. If you aren’t using the .NET classes, an average GIS scripter would find Python and IronPython indistinguishable.
Cheers,
8
Jesse Ayers
// Aug 29, 2007 at 7:52 am
IronPython is its own runtime completely separate from “regular” Python. A big limitation of it (for us) is that you cannot import many of Python’s most useful and powerful packages (e.g. numpy).
9
James Fee
// Aug 29, 2007 at 8:55 am
I know what IronPython is and have posted on its use over the past few years.
I was making a joke toward Manifold and its reliance on .NET for everything. *sigh*
10
Will
// Aug 29, 2007 at 10:03 am
They used ESRI’s well hidden documentation on the binary format and wrote their own code to handle it via JET for PGDB or a database driver in case of ArcSDE geodatabases. All this because they listen and respond to user requests in a timely fashion.
11
Milver
// Aug 29, 2007 at 11:03 am
@ Will
But if they can just copy/paste features, and you can’t edit those features (for PGDB), then we would still be locked with ESRI.
12
Will
// Aug 29, 2007 at 11:58 am
@Milver
You can read/write/edit existing features. What you cannot do is create new feature classes through Manifold.
13
KJ
// Aug 29, 2007 at 12:26 pm
I use Manifold for its personal geodatabase support and IMS - you did not need v.8 to do that. I think its important that you can stand up a web application showing your ESRI geodatabases for less than $500 in GIS server software, and in addition to PGDB you can use MapInfo tables and a host of other formats, with no extra cost for some expensive data interop module.
The interesting stuff for me also was the true 64 bit support starting at earlier versions, and the CUDA stuff at Manifold v.8. Anyone know what ESRI is thinking for 64 bit support and CUDA - or any tidbits on what ArcGIS 10.x will be about?
The thing I don’t like about manifold IMS is there is no built in way to scale a web app to multiple GIS servers, lack of built in tools for IMS (info, maptip widgets, etc), not very many sample viewers to pick apart (no cool Ajax or Flex example), and no built in tile serving and pre-rendering. But for now the cost difference between Manifold for IMS and ArcGIS Server is significant so the business case to go Manifold for map serving is more compelling (though there are many ArcGIS Server features that Manifold does not do like change only geodatabase replication, and the mobile ADF). Manifold even serves WMS that you can display in ArcGIS, which is pretty cool.
14
Dimitri
// Aug 29, 2007 at 4:55 pm
Before Release 8 personal geodatabase support was limited to imports. Release 8 extends that to read/write/edit. So now you can link a drawing from a personal geodatabase and proceed to dynamically edit objects “in place.”
You can use Administrator Console to change the projections in either an SDE data store or a personal geodatabase: however, this is not reprojection just simply changing the projection assigned. It is intended to be used in cases where the wrong projection was declared. For reprojection you can copy the contents, reproject and then export.
Interesting comment on the “tone.”
It’s always good to be reminded of how something looks from an ESRI-centric perspective .
James is right about DBMS. The emergence of spatial DBMS as a matter of primary, self-determination in the hands of the major DBMS vendors themselves changes the game. The big news in my mind in Release 8 is built-in support for SQL Server 2008 spatial.
Today there may be five sites outside Microsoft with the SQL Server 2008 spatial CTP, next week 500, next month 50,000 and by the end of the year 500,000. Not one of those people will be using SQL Server 2008 spatial to get trapped in an SDE silo. They are all going to use Microsoft’s stuff directly.
[I'm guessing at those number as I don't know what Microsoft's distribution is. But they have announced they will do an open beta soon, which usually pushes a new SQL Server distribution into the hundreds of thousands, if not millions, mark.]
A lot of those SQL Server 2008 spatial people will be using Manifold Release 8, as right now it is the only GIS product you can buy off the shelf to work with SQL Server 2008 using Microsoft’s own, native facilities. As more products come on line from other vendors, they too will use native SQL Server 2008 facilities, not SDE. That’s the nature of the Microsoft ecosystem: you make your money by leveraging Microsoft’s standards.
Unlike earlier times, when ESRI could get a toehold in a limited market where the main vendors did not have their own spatial DBMS horse in the race, right from the very beginning with Katmai it is Microsoft standards using native SQL Server 2008 facilities that are the *only* game in town.
This is very different from the Oracle world where Oracle has had to bear the annoying distraction of some alternative universe out there in the form of ESRI stuff competing with Oracle’s own native spatial technologies.
My own feeling, and I could be wrong about this, is that a very muscular Microsoft entry (and it *will* be muscular) into spatial DBMS is going to trigger a very strong competitive response from Oracle. Anyone who knows Oracle knows those guys are very serious, very effective competitors. And I just don’t see how a truly serious competition between Microsoft and Oracle on spatial DBMS leaves any room for tangents like SDE that are in nobody’s interest but ESRI.
That gets back to “tone.” I think some of that is overly dismissive of ESRI (and will give that feedback to the writers), but a lot of it is just that ESRI plays a very dwindling role as spatial DBMS emerges as a mainstream commodity. They’re almost not in the game anymore, even though I realize that from the perspective of an ESRI-centric community they still seem to be a big player.
It’s not just that we see huge things happening with SQL Server 2008. It is also the case that there are very large numbers of new users eagerly entering GIS who are very familiar with DBMS and who see spatial DBMS as something distinctly associated with the DBMS and not at all something which should be defined by third party middleware like SDE.
I assure my ESRI-centric colleagues using SDE that their willingness to define their DBMS centralization in terms specified by a third party middleware vendor who is at war with the DBMS vendor’s own standards is not something most mainstream DBMS-centric people are eager to imitate. And the more it becomes possible to work directly with a vendor’s DBMS, the less people are willing to tolerate alien middleware like SDE.
When spatial DBMS becomes completely free and you can use any DBMS you like for spatial DBMS, [as is done withManifold Release 8, which can use any DBMS as a data store for read/write/edit drawings, images or surfaces,] well, that tends to really broaden the game. In that world, SDE and personal geodatabases become extremely marginalized exotica that have no appeal to new users. They become traps to be avoided, not benefits.
All of the new users go directly to native storage within the DBMS of their choice. In that case, the advice has to be to aim new users at either something like WKB, or something like Manifold’s own Geom which is automatically converted into the native geometry type of a particular spatial DBMS, so that what is stored in a native spatial DBMS like Oracle or SQL Server 2008 is always the DBMS’s own type.
15
Dimitri
// Aug 29, 2007 at 5:11 pm
Forgot to add (how could anyone forget anything in a post that long?)…
There actually was some criticism in the Manifold beta forums that Manifold was supporting SDE and personal geodatabases for read/write/edit. The critics were saying why do this, just gives them credibility, when you should focus everything on Katmai, etc.
I’m glad it happened anyway as there are many Manifold users working with SDE and personal geodatabases and if that’s what they want that’s what the product should support. Will is right about how it happened and it was not easy, with months of beta testing and development put into it.
And I guess ultimately the decision is where it belongs, with users. People who are working with SDE data stores can continue with SDE and use them interchangeably, at the same time as other spatial DBMS. You can actually have multiple windows open at the same time with multiple spatial DBMS sources and copy and paste between them. Copy objects from a drawing in Oracle spatial and paste them into your SDE data store. Or the other way around. Manifold doesn’t care and will merrily support whatever you want.
Lots of choices will let users make true, apples-to-apples comparisons on performance and other factors and make up their own minds how they like it, choosing whichever data store they want whenever they want.
16
Milver
// Aug 29, 2007 at 9:25 pm
By all means Dimitri…please indulge us with an alternative to the ESRI world. Competition benefits the consumer, and I tend to agree with the reasoning of your argument here and in the documentation, although not with the style (aka “the tone”
). I always look forward to the best cost/benefit product (Is there a trial version?…just joking, we would break the comments section with another lengthy reply).
Now that we have used James Blog as a free Manifold forum, what do you think about the caveats presented by KJ (besides the nice capabilities that he also pointed out):
17
Mike Sumner
// Aug 29, 2007 at 9:42 pm
My answer to KJ is please send in your requests to sales@manifold.net. Follow these guidelines for making effective suggestions:
http://www.manifold.net/resources/suggestions.html
18
Dimitri
// Aug 29, 2007 at 10:32 pm
These are IMS questions, a small part of Manifold, but still cool:
“no built in way to scale a web app to multiple GIS servers,” - Yes and no. What is better than having to have multiple GIS servers is to be able to use one GIS server. The way that is done in Manifold is to use a dual-socket motherboard with two quad-core, 64-bit processors. Run 64-bit Windows, 64-bit Manifold and load that baby up with 16 GB - 32 GB of RAM. You will eat alive just about any eight machine 32-bit ArcGIS cluster and it will be ‘way easier to set up, maintain and administer than an 8 machine cluster. Cost far less, too.
No, Manifold IMS does not cluster out across multiple machines automatically (although some folks use round-robin dispatch, etc, to manually simulate this and to depend upon a clustered DBMS to hold their data). No doubt it will some day, like in six months or a year or a year and half. But in the meantime, that eight core machine has more capacity than 99.999% of GIS enabled web sites need. I suppose if you are doing million of page hits a day you have the expertise to round-robin or otherwise deal with the situation manually.
“lack of built in tools for IMS (info, maptip widgets, etc)” - ? See the user manual for the various tools such as an info button. Plenty of examples exist for people who want to code their own variations, too.
“not very many sample viewers to pick apart (no cool Ajax or Flex example), ” - ? See the examples on the Free Stuff page (the manfold legacy site). For that matter, it is not a *positive* thing that a web app *requires* a viewer. That’s a negative, as people just like to view something in an ordinary browser, like IE or Firefox.
Regarding Ajax, that is too much fun to pass up. Manifold *loves* Ajax. In fact, we love it so much there is an essay about it in the user manual. See
http://demo.manifold.net/doc/what_about_ajax_.htm
“and no built in tile serving and pre-rendering.” - plenty of tile servering. Manifold itself can function as an image server, like Virtual Earth (that’s all about tiles). There is even a “tiled” example in the Free Stuff page. Not sure what is meant by “pre-rendering.” If that is a reference to pre-computed, cached pages, Release 8 does that.
“(though there are many ArcGIS Server features that Manifold does not do like change only geodatabase replication, and the mobile ADF). “
I don’t know everything ArcGIS Server does, but no doubt there are things it does Manifold does not. But I’d bet there are far many more things Manifold does that ArcGIS Server does not do.
- I don’t know what “change only geodatabase replication is,” but given that Manifold can work with standard DBMS and things like SQL Server have exquisitely crafted replication capabilities in just about any way anyone might ever want if this is “replication” in any sense of the word as used in DBMS this is something Manifold gets by virtue of using standard enterprise DBMS. If it is a reference to versioning, that is something Manifold does automatically in multi-user editing of vector data resident in data stores. This is immediately usable in IMS, especially if one uses Manifold’s WFS-T service capability.
Regarding Mobile ADF, that’s trying to make a virtue out of a flaw. If you want mobile Manifold you put it on the mobile device. It’s not so costly that you need some special development technology to get around the unaffordability of the primary solution. If you want a thin client on some ultraportable, people do that through cell networks to web-based applications based on Manifold IMS, exploiting things like SQL Server replication for sync. Do that as a web app, and your GIS cost of the application is essentially free. Darn near zero cost of GIS. ($225 per web server).
I suppose there is a role somewhere for applications that fall between the two, perhaps some ultraportable with erratic connection, but that’s a very small niche. If you want to spend a hundred times more than you need to in order to check off a box on a check list that is really a “don’t care” for 99.999% of mobile users, well, that’s not what most people care about. They want something that serves their needs, works with utmost reliability, easy to deploy and maintain and costs a fraction of something that does not work as reliably.
Regarding the “business case”: KL hit the nail on the head there.
Manifold crushes Arc in IMS price/performance as well as in absolute performance. Consider that the eight-core example I gave at the beginning of this reply costs only $225. That’s all. $225 for a Universal x64 Runtime which replaces six or eight ArcSDE/ArcGIS server machines (who knows how much that costs!). No extra cost because you are running on eight processors in that box. No extra cost to connect to terabytes of Oracle Spatial storage, or SQL Server 2008 storage or DB2 or all the rest. And no extra cost for that tile server, the WMS server, the WFS-T feature server or the HTTP server. $225 gets it all and that’s even the 64-bit version.
One more thing about clustering: CUDA right now is used for a few dozen functions in surface transforms, but we soon will be applying it to many more functions. NVIDIA will very soon be supporting it in 64-bits and that will blow the doors off any limits to our using CUDA. It will be hundreds of functions throughout the system.
People who don’t understand CUDA don’t get the immense impact of putting into place 512 processors. Even a paltry $500 gets you 128 CUDA processors these days. So any conversation about the merits of clustering has to compare itself to the huge leap CUDA offers, to take into account the pending scale up of things like Manifold in IMS not to eight or sixteen boxes but… 512 “boxes.” Any folks out there running ArcGIS server on a server farm with 128 processors? How about 256 or 512 processors? How much is that costing you? It is astronomical numbers, millions when facilities and all the rest are counted.
What we are finding with CUDA is that the ability to run on hundreds of processors is far, far faster than clustering. And so what if it isn’t? For less than a thousand bucks you throw 200 or 300 processors at it and you don’t care if it simply scales up to be, say, 20 boxes worth of ArcGIS servers.
I’m telling you, those guys from NVIDIA are going to be changing a lot of industries with the amazing hardware magic they are deploying.
19
Petz
// Aug 30, 2007 at 12:41 am
lack of built in tools for IMS (info, maptip widgets, etc), not very many sample viewers to pick apart (no cool Ajax or Flex example)
There are third party IMS clients you can have a go with, such as Gisadvisor’s IMS template and also AtlasAlive (they are I heard even working on a Flex IMS client!).
20
Jamo
// Aug 30, 2007 at 6:49 am
I don’t care how many cool tools there are in Manifold 8. If you don’t provide a means for me to check out how worthwhile your product is (no demo available) or include a SINGLE screenshot of something impressive that your new product can do… I’m not going to be interested. Geographers are visual creatures.
Why is this image relevant to Manifold’s GIS Products Download page? http://www.manifold.net/png/scraper.png
Until Manifold fixes “no duh” issues with the delivery of their product it’s never going to make serious inroads.
21
KJ
// Aug 30, 2007 at 7:01 am
Good comments.
“Before Release 8 personal geodatabase support was limited to imports. ”
- at 7.x you can link PDGB: file->link>drawing->pick the layer->set geometry type to SHP, and your done. But you will get better performance in IMS if you unlink it (thus importing it).
“See the user manual for the various tools such as an info button. Plenty of examples exist for people who want to code their own variations, too.”
– that’s the point. You have to roll your own from scratch, and the examples out of the box are limited. This is not necessarily a bad thing, but it means you will spend less money buying the IMS, and more money getting to actually do what you want.
“For that matter, it is not a *positive* thing that a web app *requires* a viewer. That’s a negative, as people just like to view something in an ordinary browser, like IE or Firefox.”
— I know that’s Dimitri’s view and there is sense to it. However in reality I find that no-one much cares about if they need to download and install a thingy for a web site to work, expecially if its just Flash. What people care about is RIAthat rivals desktop. And security is not always an issue - IMS apps work on networks, including WANs such as the Internet, but not limited to the Internet - many organizations need to operate over secure managed IP networks with the GIS server inside their network, and not on the other side of the Internet. A reality for those of us working in Professional GIS is that now our user interfaces are compared by our customers to the new popluar Consumer GIS UIs like Google Maps, Google Earth, and Virtual Earth. A lot of Professional GIS UI’s look stale compared to the new stuff emerging on the consumer side. Its not a winning proposition to just tell our customers that the new cool consumer GIS web UIs are stupid because they have to download and install something to get them to work, and they should just stick with our powerful, but boring, classic web GIS UIs. Also - Flash and Flex are nice - why spend so much effort programming cross browser support?
“There is even a “tiled” example in the Free Stuff page. Not sure what is meant by “pre-rendering.” If that is a reference to pre-computed, cached pages, Release 8 does that”
— again, that’s the point. Why in the world do I want to spend time (e.g. money) programming a tile served web GIS app, instead of programming my own vertical market secret sauce value add? I could never come close to programming something around this that would be as good as what Manifold could. Manifold supports tile serving in a similar way to ArcIMS - which means you can use it to roll your own. “Regarding Release 8 does that” - does it for IMS on the client, or how does it support IMS?
“If you want a thin client on some ultraportable, people do that through cell networks to web-based applications based on Manifold IMS, exploiting things like SQL Server replication for sync. Do that as a web app, and your GIS cost of the application is essentially free. Darn near zero cost of GIS. ($225 per web server).”
— will not work over sometimes disconnected mobile data networks, which I can tell you from experience are not at all rare in the US. Also you cannot run the Manifold runtime on anything but a full blown MS Windows right? So these are less conducive to mobile GIS.
“Any folks out there running ArcGIS server on a server farm with 128 processors? How about 256 or 512 processors? How much is that costing you? It is astronomical numbers”
— you got that right. So at that scale, why not instead spend the $$ custom programming the broad horizontal stuff into Manifold, and paying once for the custom dev? You just can’t ignore that business case.
“There are third party IMS clients you can have a go with, such as Gisadvisor’s IMS template and also AtlasAlive (they are I heard even working on a Flex IMS client!).”
— again, goes to the point - that stuff costs extra. I know a bit about AtlasAlive and have hired Dennis for lots of work in the past. I highly recommend him. My point is, you can pretty fast burn throgh $30K custom programming on Manifold IMS to make it do some things that AGS does out of the box. Does it make sense to do that? I think more so if you are an ISV looking to resell your app to customers, and less so if you are a city or county looking to stand up one server. So my only point is that if you are really going to stand up a web GIS app, you can do it on Manifold IMS for a couple hundred dollars, but do not think that you will not spend some money molding your web app to be what you want. Now, not too many serious developers use the canned AGS viewers either, so its always an anaylis - what do I need to custom program, what is available out of the box, where do I get the most value from spending my custom programming dollar, and what are the costs to start up and scale. Well, lots of other factors too I guess - its a complex equation. But for me, for reselling and hosting web apps for customers, the equation definitley tips towards Manifold and away from AGS.
“My answer to KJ is please send in your requests to sales@manifold.net. Follow these guidelines for making effective suggestions:”
— Manifold guys always telling me to read the help ;-). Believe me I know this, and I have read it many times! I have already submitted my IMS requests to Manifold. I am hopeful for a version release that focuses on IMS, since it looks like there is a lot of low hanging fruit out there for it. The past few versions have not touched it very much.
22
Chris C.
// Aug 30, 2007 at 7:16 am
@ Jamo
I’ll give you that on the image - what’s that all about?!
23
Dimitri
// Aug 30, 2007 at 8:04 am
“Why is this image relevant to Manifold’s GIS Products Download page? http://www.manifold.net/png/scraper.png “
The page is where people can click in their browsers to download software. The image shows a machine harvesting IE logos (the little blue things) and outputting the results, little program buttons, etc. into a truck. It is a whimsical visual metaphor for the process of delivery of software using IE, deliberately using an agricultural setting to contrast with the high tech nature of the task, as if programs were potatoes and not virtual things. It has been used before, notably a couple of years ago for the Database Commander web page, and had accumulated a fair amount of fan mail so it was used again.
There are plenty of product images in the user manual (check out the tutorial topic, for example) or on the legacy web site, which can be reached through the small link at the bottom of any of the pages.
Regarding:
“will not work over sometimes disconnected mobile data networks, which I can tell you from experience are not at all rare in the US. Also you cannot run the Manifold runtime on anything but a full blown MS Windows right? So these are less conducive to mobile GIS.”
That’s exactly correct. I agree that the strategy is not for everyone and the case of using an ultrathin client on an ultraportable that depends upon Internet connectivity will not work on mobile data networks with erratic connections. So, no go for certain wilderness environments.
But those are fewer and fewer to be found as the cell cloud increasingly covers every square inch of the continent.
Regarding use of full blown MS Windows, that too is really a positive, not a negative. A lot of us at Manifold are ex-Intel guys, so we have almost religious faith in the notion that devices *will* get smaller and *will* get cheaper and *will* get more powerful, all at the same time.
I grant you that it has taken a year or two longer than expected, but this year we already see the emergence of UMPCs that run standard Windows. True, very-thin PDA-style devices the size of a cell phone that run standard Windows are just around the corner.
If that is the case, it does not make sense either for GIS software vendors or for GIS mobile applications developers to want to use anything but the standard GIS package in the mobile environment.
You’ve already spent your expensive time learning how to code the standard GIS package’s API - why should you now have to learn some entirely separate development environment to code mobile applications? That’s the ESRI approach.
The Manifold is to say “run the standard package” - use what you already know how to do.
From the vendor side it also makes more sense to invest all developmental resources into the main package instead of peeling off resources to spend a couple of years creating some “mobility” variant that is just a limited, lobotomized version of the main thing. That special variant will always be six months or a year behind any improvements in the main thing and it will cost you more than it needs to because you will have to pay for the sustenance of a special-case thing.
With Manifold you get to ride on the volume of the main package. Deploy with a professional runtime, which is only $50 in volume. Any improvement to Manifold (better multi-core usage? 64-bits?) automatically happens in what you are using for mobile apps. By the way, it’s not a joke to consider multi-core/64-bit function within cell-phone sized devices, as that is where the industry is going.
The other virtue of UMPCs is that they have very large screens with much more user-friendly and productive displays than PDAs. If you make the case that GIS guys have to compete with the likes of Google Earth, don’t forget that applies in mobility as well, where the iPhone is setting a new standard for what is expected in sleek visual interfaces.
So there’s a bifurcation in what you can do mobile with Manifold: use a thin client and go for a purely web app via cell network and that is the small form factor solution today. For example, it is dazzling what folks like ScanControl are doing with this in vineyard management.
Or, you go with a slightly larger form factor (and I’ll be the first agree that UMPCs really need the next generation of shrink to be what we all want them to be, especially after iPhone raised expectations all around) and run the application in the handheld.
24
KJ
// Aug 30, 2007 at 8:19 am
Thanks for that. UMPCs are a good point. I would be happy if windows mobile was just windows. You are right, I do not like programming to different APIs for mobile, dekstop, and web (and sometimes 2 different versions of web - one that can access resources form the Internet, and one that cannot). Anytime I create something I have to kind of like make three versions of it.
25 BostonGIS Blog // Sep 1, 2007 at 9:51 pm
[...] e.g A manifold blogger and just general web stumbling. For example we see James blog has a lot of rants and raves about Manifold and Simon Greener, seems to like it and details it in his Mainfold Tips and Tricks, granted those [...]
26
Mike C.
// Sep 20, 2007 at 7:22 am
One comment on the IMS scale out…
I believe that the Manifold strategy is to use the underlying technology to provide capabilities. In this respect, you scale out the IIS (e.g. network load balancing and shared state server) all as *independant* nodes of a web map application. In this manner, Manifold does not *need* to provide some vendor specific mechanism for distributing the load.
27
Dimitri
// Sep 20, 2007 at 2:56 pm
That’s true about IMS scale out. Another good example of using underlying technology is Manifold’s use of native spatial DBMS.
If you connect natively to something like Oracle Spatial or Katmai you automatically get the benefit of the host DBMS’s scaling capabilities, which in the case of Oracle, DB2, Katmai, etc., are both huge and very well understood.
An IMS application for which scale out is a concern will almost certainly revolve around some DBMS, and it is likewise almost certain that the organization running such big time IMS applications has already made a very deep commitment to some particular DBMS and has scaled out their DBMS infrastructure. Manifold will simply use that. Just deploy however many nodes you want.
But I also want to emphasize that having 64-bit Manifold available just might mean that you won’t have to deploy extra nodes even for very intensively used web sites. Fast servers with two sockets hosting quad-core processors in each socket can be equipped in 64-bit environments with 16 or even 32 gigabytes of RAM.
Such a machine front-ending your terabyte coporate DBMS cluster will be able to host many IMS applications that are literally nationwide in scale, yet the hardware is inexpensive enough that one can deploy it for a mere few hundred thousand hits a day. And if you need more (ir if you just want hardware redundancy) you plug in another such machine as Mike C. pointed out.
Leave a Comment