Note you may still want to proxy for security reasons even if using eval().
Also, small platforms may not support eval() (as adamhill mentions).
crschmidt mentioned (on #openlayers) that being able to directly query
third party servers from your rich javascript client does let you do
authentication more easily however.... I haven't heard that mentioned
elsewhere.
For mobile one of course has another choice; which is just to write
real code without any shackles... In that case there is an incentive
to try to encourage a binary blob format... Mobile apps will probably
start to look prettier (and even more annoyingly bewildering) than the
web soon ( arguably the iphone UI is a lead on that trend; but it's
just a natural direction once html/javascript is thrown out the
window) .
Also note GML/JSON is probably not a good transport for data for
mobile anyway. Chris Goad mentioned a defect with regards to GML
encoding number pairs as a single literal string - which is actually
difficult for even XSLT to transform; and an annoyance for javascript
or a native j2me app to have to transform. There are other defects;
such as the previously mentioned lack of multiple instancing of
geometry, and the lack of an ability to share vertices between
polygons. The way styling is expressed may also be a concern; KML
does it differently yet again for example...
- a
On 2/8/07, Allan Doyle <[EMAIL PROTECTED]> wrote:
On Feb 8, 2007, at 13:11, Mike Liebhold wrote:
> joshua wrote:
>> the point of json is that it can be dynamically cross-site
>> included via <script>
>
> Thanks Joshua,
>
> I am interpereting json's capability to include objects fom other
> sites to be potenially useful, along with safari's javascript
> rendering for a rich but lightweight map client experience for
> iPhone users, served from the net, That coupled with a wifi
> location lookup, despite the platform's nominally closed
> environment, might still leave the iPhone as an attractive platform
> for location services.
Assuming you can get your hands on the wifi info. Even if the iPhone
has something like iwtools, it's not clear to me how to get at that
info via javascript.
>
> There have been many comments here and elsewhere over many months
> about the relative [lack of] suitability of other target devices
> for mobile geo hacking like treos, blackberrys, ipaqs, axims,
> crippled blue tooth connected phones, opaque screened tablets, and
> too heavy laptops. It's nice to see a cool device on the horizon
> that might be relatively easy to use and to develop net served
> mobile geo services, and that the better of these services stand a
> chance of being used by more than a handful of a developers best
> friends.
For locative hackability, the N770 and N800 (although I don't yet
have an N800) are pretty decent.
Allan
>
>
>
>
>
>> Mike Liebhold wrote:
>>> so if JSON works in Safari, which Anselm assures me is true;
>>> Then there's fine prospects, after all, for mapping and location
>>> apps on the iphone within community wifi nets ( e.g. San
>>> Francisco) --- using a wifi mac address lookup for geolocation.
>>>
>>>
>>> Anselm Hook wrote:
>>>> As Cameron points out XML is slower and I suspect many web 2.0 type
>>>> projects are now using JSON exclusively.
>>>>
>>>> The problem however is that there's no formalization of how to
>>>> shape JSON.
>>>>
>>>> We're still stuck at the "syntax" instead of the "semantics".
>>>> So in
>>>> the switch to JSON we've lost inter-application and inter-vender
>>>> dialogue; except by those vendors also going out of their way to
>>>> offer
>>>> traditional RDF/XML or GeoRSS or the like.
>>>>
>>>> JDIL would permit users to mix-and match content from different
>>>> servers; without application developers having to resort to RDF/
>>>> XML.
>>>> So this makes it a good thing.
>>>>
>>>> It also (like RDF) is a "full" notation; able to express
>>>> arbitrarily
>>>> complex graphs; not just directed-acyclic trees. You could for
>>>> example define a geometry namespace and then define a 50000 polygon
>>>> house and then instance it 50 times; to say describe a city
>>>> sub-division. Neither GML nor GeoRSS support this as far as I can
>>>> figure.
>>>>
>>>> And it's also JSON... which is beautiful and elegant as opposed
>>>> to say XML.
>>>>
>>>> To support JDIL the application developers job would be to is
>>>> formalize whatever ad-hoc JSON format they are publishing and to
>>>> possibly offer proxy gateways to get around rpc security issues.
>>>>
>>>> What's especially interesting is that there's an incentive to
>>>> use JDIL
>>>> even if nobody else is.
>>>>
>>>> In one of my projects I publish JSON - for example:
>>>>
>>>> http://hook.org/note/json_query?path=/venice/chat
>>>>
>>>> There is no particular way that my object data is arranged
>>>> except as
>>>> an implicit agreement between my server side Ruby On Rails database
>>>> and my client side Javascript application. In fact the only way
>>>> that
>>>> I myself as the developer can know or share what is being
>>>> published is
>>>> to send somebody a copy of the source code for the application;
>>>> I have
>>>> no schema definition on the transport layer. If I switch to using
>>>> JDIL instead of just JSON then that self-imposed formalism makes my
>>>> data-structures more explicit to myself. It becomes a secondary
>>>> benefit that other people can subscribe to the streams of
>>>> content that
>>>> I publish.
>>>>
>>>> There was a bit of discussion about Chris'es idea on #swig and the
>>>> following URL came up which has some interesting thoughts about
>>>> encoding RDF in JSON:
>>>>
>>>> http://www.thefigtrees.net/lee/blog/2007/01/
>>>> using_rdf_on_the_web_a_vision.html
>>>>
>>>> Some lessons from being a game developer - and having to transport
>>>> data between servers and clients (albeit more for 3d video games
>>>> rather than for webby 2.0 social apps):
>>>>
>>>> People defining new grammers for vector geometry may want to
>>>> remember
>>>> to keep VRML and X3D in mind; these are grammers that express
>>>> not just
>>>> static content but things like multiple instancing, separation of
>>>> skinning from geometry, switch nodes and behavior nodes as well as
>>>> constraints.
>>>>
>>>> As well, and why JSON appeals, is that one definately seeks some
>>>> kind
>>>> of grammer that is terse, highly expressive and that can be
>>>> "unpacked"
>>>> with a minimum of labour on the client side. Typically a client
>>>> side
>>>> is less powerful than the server side; it is easiest to just "play
>>>> back" the content; not have to parse it. Javascript in
>>>> particular is
>>>> mind-numblingly slow at doing array inserts and the like; it isn't
>>>> even just the XML parsing... you really don't want to do any
>>>> transformation on the data once you get it if at all possible.
>>>>
>>>> Finally, rich client apps are usually going to have some kind of
>>>> "read
>>>> through" database; even for just a single sessions activity.
>>>> Javascript clients often will have a caching read through query
>>>> layer;
>>>> where queries only make it to the server if the client does not
>>>> have
>>>> the data cached already. So the data transport model should
>>>> allow one
>>>> to easily add new database columns or objects to an already
>>>> existing
>>>> pool of data on the client (not just replace it).
>>>>
>>>> - a
>>>> _______________________________________________
>>>> Geowanking mailing list
>>>> [email protected]
>>>> http://lists.burri.to/mailman/listinfo/geowanking
>>>>
>>>>
>>> _______________________________________________ Geowanking
>>> mailing list [email protected] http://lists.burri.to/
>>> mailman/listinfo/geowanking
>> _______________________________________________ Geowanking mailing
>> list [email protected] http://lists.burri.to/mailman/
>> listinfo/geowanking
> _______________________________________________
> Geowanking mailing list
> [email protected]
> http://lists.burri.to/mailman/listinfo/geowanking
--
Allan Doyle
+1.781.433.2695
[EMAIL PROTECTED]
_______________________________________________
Geowanking mailing list
[email protected]
http://lists.burri.to/mailman/listinfo/geowanking
_______________________________________________
Geowanking mailing list
[email protected]
http://lists.burri.to/mailman/listinfo/geowanking
