Hey all, I''m wondering about your thoughts on upgrading the Geocoder to use Mapstraction V2. Currently it uses the old syntax (i.e., for LatLonPoint, etc.): http://mapstraction.appspot.com/#geocoding Moving from V1 to V2 is fairly simple changes to the code. However, I wonder whether we want to update the way the geocoder is structured, as well? Some options: 1) Roll geocoding into core, so that each provider could implement the interface. (Right now only Google is implemented). 2) Keep the geocoder a single separate file, but allow it to be loaded like providers are loaded: i.e., mxn.js?(google, yahoo, geocoder) 3) Keep the geocoder exactly as it is now, only upgraded to the V2 syntax. 4) Some other, more genius option? Looking forward to your ideas/opinions! --Adam --- Adam DuVander I like maps: http://mapscripting.com I like simple: http://adamduvander.com
good question. comments below On Thu, Oct 22, 2009 at 08:18, Adam DuVander <mapstraction at duvander.com> wrote:> Hey all, > > I''m wondering about your thoughts on upgrading the Geocoder to use > Mapstraction V2. Currently it uses the old syntax (i.e., for LatLonPoint, > etc.): > http://mapstraction.appspot.com/#geocoding >I vote for upgrading as part of general move to get everyone, and all mxn dev momentum, to v2> Moving from V1 to V2 is fairly simple changes to the code. However, I wonder > whether we want to update the way the geocoder is structured, as well? Some > options: > 1) Roll geocoding into core, so that each provider could implement the > interface. (Right now only Google is implemented). > 2) Keep the geocoder a single separate file, but allow it to be loaded like > providers are loaded: i.e., mxn.js?(google, yahoo, geocoder)I like this option. My current project doesn''t need the geocoder, so it seems optimal to be able to add or not add it as needed.> 3) Keep the geocoder exactly as it is now, only upgraded to the V2 syntax. > 4) Some other, more genius option? > > Looking forward to your ideas/opinions! >thanks for pushing the discussion> --Adam > --- > Adam DuVander > I like maps: http://mapscripting.com > I like simple: http://adamduvander.com > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >
Hi Adam, the system has been designed to have plugins such as this included as seperate files (your option 2). This way users can just include the js files and subsequent page size overhead for what they need. The script loading works such that: mxn.js?(google, yahoo, [geocoder]) would load the google and yahoo libraries with a plugin named ''geocoder'' for each. The files would need to be called: mxn.yahoo.geocoder.js -and- mxn.yahoo.geocoder.js I am tinkering with this script loading as I find the time to get it working on webkit browsers. Cheers, Rob 2009/10/22 Adam DuVander <mapstraction at duvander.com>> Hey all, > > I''m wondering about your thoughts on upgrading the Geocoder to use > Mapstraction V2. Currently it uses the old syntax (i.e., for LatLonPoint, > etc.): > http://mapstraction.appspot.com/#geocoding > > Moving from V1 to V2 is fairly simple changes to the code. However, I > wonder whether we want to update the way the geocoder is structured, as > well? Some options: > 1) Roll geocoding into core, so that each provider could implement the > interface. (Right now only Google is implemented). > 2) Keep the geocoder a single separate file, but allow it to be loaded like > providers are loaded: i.e., mxn.js?(google, yahoo, geocoder) > 3) Keep the geocoder exactly as it is now, only upgraded to the V2 syntax. > 4) Some other, more genius option? > > Looking forward to your ideas/opinions! > > --Adam > --- > Adam DuVander > I like maps: http://mapscripting.com > I like simple: http://adamduvander.com > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20091022/0b9e54ca/attachment.htm>
Rob, Any examples of the plugin architecture in action? Before porting the Geocoder, I''m just trying a proof of concept. When I include the [plugin] the browser is unable to recognize mxn.Mapstraction as a constructor. --Adam --- Adam DuVander I like maps: http://mapscripting.com I like simple: http://adamduvander.com On Oct 22, 2009, at 1:25 AM, Rob wrote:> Hi Adam, > > the system has been designed to have plugins such as this included > as seperate files (your option 2). This way users can just include > the js files and subsequent page size overhead for what they need. > The script loading works such that: > > mxn.js?(google, yahoo, [geocoder]) > > would load the google and yahoo libraries with a plugin named > ''geocoder'' for each. > > The files would need to be called: > > mxn.yahoo.geocoder.js > -and- > mxn.yahoo.geocoder.js > > I am tinkering with this script loading as I find the time to get it > working on webkit browsers. > > Cheers, > Rob > > > 2009/10/22 Adam DuVander <mapstraction at duvander.com> > Hey all, > > I''m wondering about your thoughts on upgrading the Geocoder to use > Mapstraction V2. Currently it uses the old syntax (i.e., for > LatLonPoint, etc.): > http://mapstraction.appspot.com/#geocoding > > Moving from V1 to V2 is fairly simple changes to the code. However, > I wonder whether we want to update the way the geocoder is > structured, as well? Some options: > 1) Roll geocoding into core, so that each provider could implement > the interface. (Right now only Google is implemented). > 2) Keep the geocoder a single separate file, but allow it to be > loaded like providers are loaded: i.e., mxn.js?(google, yahoo, > geocoder) > 3) Keep the geocoder exactly as it is now, only upgraded to the V2 > syntax. > 4) Some other, more genius option? > > Looking forward to your ideas/opinions! > > --Adam > --- > Adam DuVander > I like maps: http://mapscripting.com > I like simple: http://adamduvander.com > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >
I''m not sure the geocoder warrants the full deconstruction into API specific files - it''s probably more effort for the browser to set up another connection than it is to just download the bit of extra code in that case. May even be better just bringing the geocoder into the core, what are folks opinions on that? Also, where are we at with the WebKit lazy loading issues? Derek 2009/11/10 Adam DuVander <mapstraction at duvander.com>> Rob, > > Any examples of the plugin architecture in action? Before porting the > Geocoder, I''m just trying a proof of concept. When I include the [plugin] > the browser is unable to recognize mxn.Mapstraction as a constructor. > > > --Adam > --- > Adam DuVander > I like maps: http://mapscripting.com > I like simple: http://adamduvander.com > > On Oct 22, 2009, at 1:25 AM, Rob wrote: > > Hi Adam, >> >> the system has been designed to have plugins such as this included as >> seperate files (your option 2). This way users can just include the js files >> and subsequent page size overhead for what they need. >> The script loading works such that: >> >> mxn.js?(google, yahoo, [geocoder]) >> >> would load the google and yahoo libraries with a plugin named ''geocoder'' >> for each. >> >> The files would need to be called: >> >> mxn.yahoo.geocoder.js >> -and- >> mxn.yahoo.geocoder.js >> >> I am tinkering with this script loading as I find the time to get it >> working on webkit browsers. >> >> Cheers, >> Rob >> >> >> 2009/10/22 Adam DuVander <mapstraction at duvander.com> >> Hey all, >> >> I''m wondering about your thoughts on upgrading the Geocoder to use >> Mapstraction V2. Currently it uses the old syntax (i.e., for LatLonPoint, >> etc.): >> http://mapstraction.appspot.com/#geocoding >> >> Moving from V1 to V2 is fairly simple changes to the code. However, I >> wonder whether we want to update the way the geocoder is structured, as >> well? Some options: >> 1) Roll geocoding into core, so that each provider could implement the >> interface. (Right now only Google is implemented). >> 2) Keep the geocoder a single separate file, but allow it to be loaded >> like providers are loaded: i.e., mxn.js?(google, yahoo, geocoder) >> 3) Keep the geocoder exactly as it is now, only upgraded to the V2 syntax. >> 4) Some other, more genius option? >> >> Looking forward to your ideas/opinions! >> >> --Adam >> --- >> Adam DuVander >> I like maps: http://mapscripting.com >> I like simple: http://adamduvander.com >> >> _______________________________________________ >> Mapstraction mailing list >> Mapstraction at lists.mapstraction.com >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> >> > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >-- Derek Fowler m. +44 (0) 7966 512 369 e. dezfowler at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20091110/c86b47de/attachment.htm>
On Tue, Nov 10, 2009 at 09:07, Derek Fowler <dezfowler at gmail.com> wrote:> I''m not sure the geocoder warrants the full deconstruction into API specific > files - it''s probably more effort for the browser to set up another > connection than it is to just download the bit of extra code in that > case.?May even be better just bringing the geocoder into the core, what are > folks opinions on that?I''d prefer if the geocoder were not in the core. I don''t need the geocoder, so why make my users download it? My concern is that today it''s the geocoder, but later it''s the next thing, and then over time core becomes bigger and bigger. I''d much prefer a more modular solution. my 2 cents, Ed> Also, where are we at with the WebKit lazy loading issues? > Derek > 2009/11/10 Adam DuVander <mapstraction at duvander.com> >> >> Rob, >> >> Any examples of the plugin architecture in action? Before porting the >> Geocoder, I''m just trying a proof of concept. When I include the [plugin] >> the browser is unable to recognize mxn.Mapstraction as a constructor. >> >> --Adam >> --- >> Adam DuVander >> I like maps: http://mapscripting.com >> I like simple: http://adamduvander.com >> >> On Oct 22, 2009, at 1:25 AM, Rob wrote: >> >>> Hi Adam, >>> >>> the system has been designed to have plugins such as this included as >>> seperate files (your option 2). This way users can just include the js files >>> and subsequent page size overhead for what they need. >>> The script loading works such that: >>> >>> mxn.js?(google, yahoo, [geocoder]) >>> >>> would load the google and yahoo libraries with a plugin named ''geocoder'' >>> for each. >>> >>> The files would need to be called: >>> >>> mxn.yahoo.geocoder.js >>> -and- >>> mxn.yahoo.geocoder.js >>> >>> I am tinkering with this script loading as I find the time to get it >>> working on webkit browsers. >>> >>> Cheers, >>> Rob >>> >>> >>> 2009/10/22 Adam DuVander <mapstraction at duvander.com> >>> Hey all, >>> >>> I''m wondering about your thoughts on upgrading the Geocoder to use >>> Mapstraction V2. Currently it uses the old syntax (i.e., for LatLonPoint, >>> etc.): >>> http://mapstraction.appspot.com/#geocoding >>> >>> Moving from V1 to V2 is fairly simple changes to the code. However, I >>> wonder whether we want to update the way the geocoder is structured, as >>> well? Some options: >>> 1) Roll geocoding into core, so that each provider could implement the >>> interface. (Right now only Google is implemented). >>> 2) Keep the geocoder a single separate file, but allow it to be loaded >>> like providers are loaded: i.e., mxn.js?(google, yahoo, geocoder) >>> 3) Keep the geocoder exactly as it is now, only upgraded to the V2 >>> syntax. >>> 4) Some other, more genius option? >>> >>> Looking forward to your ideas/opinions! >>> >>> --Adam >>> --- >>> Adam DuVander >>> I like maps: http://mapscripting.com >>> I like simple: http://adamduvander.com >>> >>> _______________________________________________ >>> Mapstraction mailing list >>> Mapstraction at lists.mapstraction.com >>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>> >> >> _______________________________________________ >> Mapstraction mailing list >> Mapstraction at lists.mapstraction.com >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > > > -- > Derek Fowler > m. +44 (0) 7966 512 369 > e. dezfowler at gmail.com > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >
I feel its better separated, Its not too difficult for anyone to merge all they need into a single script as a post-production task. Or we could even offer a custom download service where users select the modules they require and we merge and compress for them. The webkit issue is still ongoing, a lot on my plate ATM, but have got a lot of code examples to look through :) 2009/11/10 Ed Freyfogle <edf at sloan.mit.edu>> On Tue, Nov 10, 2009 at 09:07, Derek Fowler <dezfowler at gmail.com> wrote: > > I''m not sure the geocoder warrants the full deconstruction into API > specific > > files - it''s probably more effort for the browser to set up another > > connection than it is to just download the bit of extra code in that > > case. May even be better just bringing the geocoder into the core, what > are > > folks opinions on that? > > I''d prefer if the geocoder were not in the core. I don''t need the > geocoder, so why make my users download it? > My concern is that today it''s the geocoder, but later it''s the next > thing, and then over time core becomes bigger and bigger. I''d much > prefer a more modular solution. > > my 2 cents, > Ed > > > Also, where are we at with the WebKit lazy loading issues? > > Derek > > 2009/11/10 Adam DuVander <mapstraction at duvander.com> > >> > >> Rob, > >> > >> Any examples of the plugin architecture in action? Before porting the > >> Geocoder, I''m just trying a proof of concept. When I include the > [plugin] > >> the browser is unable to recognize mxn.Mapstraction as a constructor. > >> > >> --Adam > >> --- > >> Adam DuVander > >> I like maps: http://mapscripting.com > >> I like simple: http://adamduvander.com > >> > >> On Oct 22, 2009, at 1:25 AM, Rob wrote: > >> > >>> Hi Adam, > >>> > >>> the system has been designed to have plugins such as this included as > >>> seperate files (your option 2). This way users can just include the js > files > >>> and subsequent page size overhead for what they need. > >>> The script loading works such that: > >>> > >>> mxn.js?(google, yahoo, [geocoder]) > >>> > >>> would load the google and yahoo libraries with a plugin named > ''geocoder'' > >>> for each. > >>> > >>> The files would need to be called: > >>> > >>> mxn.yahoo.geocoder.js > >>> -and- > >>> mxn.yahoo.geocoder.js > >>> > >>> I am tinkering with this script loading as I find the time to get it > >>> working on webkit browsers. > >>> > >>> Cheers, > >>> Rob > >>> > >>> > >>> 2009/10/22 Adam DuVander <mapstraction at duvander.com> > >>> Hey all, > >>> > >>> I''m wondering about your thoughts on upgrading the Geocoder to use > >>> Mapstraction V2. Currently it uses the old syntax (i.e., for > LatLonPoint, > >>> etc.): > >>> http://mapstraction.appspot.com/#geocoding > >>> > >>> Moving from V1 to V2 is fairly simple changes to the code. However, I > >>> wonder whether we want to update the way the geocoder is structured, as > >>> well? Some options: > >>> 1) Roll geocoding into core, so that each provider could implement the > >>> interface. (Right now only Google is implemented). > >>> 2) Keep the geocoder a single separate file, but allow it to be loaded > >>> like providers are loaded: i.e., mxn.js?(google, yahoo, geocoder) > >>> 3) Keep the geocoder exactly as it is now, only upgraded to the V2 > >>> syntax. > >>> 4) Some other, more genius option? > >>> > >>> Looking forward to your ideas/opinions! > >>> > >>> --Adam > >>> --- > >>> Adam DuVander > >>> I like maps: http://mapscripting.com > >>> I like simple: http://adamduvander.com > >>> > >>> _______________________________________________ > >>> Mapstraction mailing list > >>> Mapstraction at lists.mapstraction.com > >>> > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >>> > >> > >> _______________________________________________ > >> Mapstraction mailing list > >> Mapstraction at lists.mapstraction.com > >> > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > > > > > > > -- > > Derek Fowler > > m. +44 (0) 7966 512 369 > > e. dezfowler at gmail.com > > > > _______________________________________________ > > Mapstraction mailing list > > Mapstraction at lists.mapstraction.com > > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > > > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20091110/659ba2a2/attachment-0001.htm>