Hi,

* Paco <manuel.arguelles@...> [20080512 07:51]:
> Is there any intentions to remove mac address of plazes? It doesn't
> seem to be documented in plazes.net (just a bit as a search for a
> plaze method).
>
> I'm asking because I want to build a plazer an without this I will
> have to ask the user to select his plaze everytime the plazer
> starts.

It's now optional on plazes.net to specify mac_address or any other
network identifier, on presence creation and on search. There is no
intention to remove this feature.

If you have access to a router mac_address from your plazer then it
makes sense to post it with presence creation and use it for the
search, then your plazer can come up with the right plaze when the
mac_address is already known.


Til

Hello,

Is there any intentions to remove mac address of plazes? It doesn't seem to be
documented in plazes.net (just a bit as a search for a plaze method).

I'm asking because I want to build a plazer an without this I will have to ask
the user to select his plaze everytime the plazer starts.

BR


      
________________________________________________________________________________\
____
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now. 
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Hi,

--- In plazesapi@yahoogroups.com, Tilmann Singer <til@...> wrote:
> Obviously the two geocoding algorithms of plazes and fireeagle produce
> slightly different results in certain cases - so for those cases where
> fireeagles' is better it makes sense to send the user input then the
> coordinates.

Well, I don't know which one is better - I just notice they are
different. :)

> If this occurs with one specific plaze, you could manually adjust the
> location by clicking on 'edit' on the plaze page and dragging the pin
> to where the plaze actually is and save it. Just don't change the text
> of the address at the same time, otherwise the coordinates will be
> geocoded again and override the manually set location.

Okay, thanks, I'll try that. :)

Dominik

* Dominik Schwind <dschwind@...> [20080506 15:33]:
> > One would think that latitude/longitude are more exact than a freeform
> > text that needs to be normalized and "reformated" depending on what
> > the provider needs and wants, etc.. So IM(H)O, latitude and longitude
> > are good. If Fireeagle places you on the wrong street (based on
> > latitude and longitude) than that is there bug. :P
>
> Well, I don't have a GPS here to verify whose data is right - the
> lat/long that Plazes is giving me for the address or the lat/long that
> Fireeagle would give me. :)

Thanks for the feedback - my colleague who works on the fireeagle
integration promised he will sometime soon experiment with sending the
address text data that the user has input into plazes instead of the
coordinates. Unfortunately it needs to be changed on our side first
because right now we are storing the normalized text data from the
geocoding, not the user input.

Obviously the two geocoding algorithms of plazes and fireeagle produce
slightly different results in certain cases - so for those cases where
fireeagles' is better it makes sense to send the user input then the
coordinates.


> But either way it is a bit weird/annoying and I'll have to switch the
> plazes/fireeagle integration off, for the time being.

If this occurs with one specific plaze, you could manually adjust the
location by clicking on 'edit' on the plaze page and dragging the pin
to where the plaze actually is and save it. Just don't change the text
of the address at the same time, otherwise the coordinates will be
geocoded again and override the manually set location.



greetings, Til

--- In plazesapi@yahoogroups.com, till <klimpong@...> wrote:
>
> One would think that latitude/longitude are more exact than a freeform
> text that needs to be normalized and "reformated" depending on what
> the provider needs and wants, etc.. So IM(H)O, latitude and longitude
> are good. If Fireeagle places you on the wrong street (based on
> latitude and longitude) than that is there bug. :P

Well, I don't have a GPS here to verify whose data is right - the
lat/long that Plazes is giving me for the address or the lat/long that
Fireeagle would give me. :)

But either way it is a bit weird/annoying and I'll have to switch the
plazes/fireeagle integration off, for the time being.

Dominik

On Tue, May 6, 2008 at 12:01 PM, Dominik Schwind <dschwind@...> wrote:
> Hi,
>
>  it seems to me that Plazes is updating Fire Eagle using the Lat/Long,
>  am I right about that?
>
>  This way it quite often doesn't place me at the right street, though.
>  The place I am at the moment -
>  http://plazes.com/plazes/6504_media_ventures_k - gives me a different
>  street on Fire Eagle. Given that the Fire Eagle geo database is quite
>  good, wouldn't it make more sense to update via the freetext form with
>  the full address of the place?
>
>  Regards,
>
>  Dominik

One would think that latitude/longitude are more exact than a freeform
text that needs to be normalized and "reformated" depending on what
the provider needs and wants, etc.. So IM(H)O, latitude and longitude
are good. If Fireeagle places you on the wrong street (based on
latitude and longitude) than that is there bug. :P

Till

Hi,

it seems to me that Plazes is updating Fire Eagle using the Lat/Long,
am I right about that?

This way it quite often doesn't place me at the right street, though.
The place I am at the moment -
http://plazes.com/plazes/6504_media_ventures_k - gives me a different
street on Fire Eagle. Given that the Fire Eagle geo database is quite
good, wouldn't it make more sense to update via the freetext form with
the full address of the place?

Regards,

Dominik

* till <klimpong@...> [20080428 15:44]:
> when moving, do you guys create a new plaze? Even though it's the same
> hotspot, or do you edit your routers plaze? Does plazes keep the
> history somewhere or is it lost when you edit your plaze?

The way it's intended from Plazes is that a plaze represents a
specific, _static_ location on earth, with enough information so that
it is identifiable and meaningful to humans, around which a social
history evolves. So when moving to another office, that would
definitely be a _different_ plaze, and it would start a new history,
with new visitors etc. For example there would certainly be people who
have been to your previous office but not to your current one and that
would correctly be represented when having two different plazes for
the two different offices. You could link these two plazes
e.g. through a comment, to enable discovery of these relations.

When moving a router to a new plaze, it's just a matter of plazing
yourself manually with the plazer once in the new plaze, and from then
on the new plaze should show up before the old one when retrieving
suggestions for the routers mac address.



Til

--
Sent from Wicke, Vienna
http://plazes.net/users/til/presence              http://tils.net
Tilmann Singer

Hey guys,

when moving, do you guys create a new plaze? Even though it's the same
hotspot, or do you edit your routers plaze? Does plazes keep the
history somewhere or is it lost when you edit your plaze?

Lot's of question(mark)s. :-)

Till

* Andy Piper <andypiperuk@...> [20080424 15:32]:
> Tilmann Singer wrote:
> > Did you enter a specific post code into the plaze edit form on
> > plazes.com, saved the form and it saved it without errors but it cut
> > off the last couple of digits/alphas from the zip code?
>
> Yes, exactly that... Plazes seems to drop the second part of the
> postcode (they are usually 2+3 or 3+3 or 4+3 codes and Plazes
> only saves the first part). I'll mail you off-list about the
> specifics.

I see. Apparently the geocoding that we use is resolving post codes in
the UK only down to a certain accuracy, and is not able to
differentiate between different sections of a street if the house
number is missing, based on the post code alone.

I'm afraid there is nothing that can immediately be done about it in
this particular case.

After inputting an address into plazes, the input is normalized to
what the geocoding understood, and that is what is sent to
fireeagle. Keeping the original user input and sending that instead to
fireeagle should be possible but would require some
restructuring. We'll keep this issue in mind.


Til

Tilmann Singer wrote:
> Did you enter a specific post code into the plaze edit form on
> plazes.com, saved the form and it saved it without errors but it cut
> off the last couple of digits/alphas from the zip code?

Yes, exactly that... Plazes seems to drop the second part of the
postcode (they are usually 2+3 or 3+3 or 4+3 codes and Plazes
only saves the first part). I'll mail you off-list about the
specifics.

--
http://andypiper.wordpress.com/

* Andy Piper <andypiperuk@...> [20080423 19:14]:
> If I go to the Fire Eagle site and type in my full postcode (UK
> equivalent of zip code) it places me correctly. But on Plazes, it will
> only allow me to enter the first four characters of the postcode, and
> subsequently gets the wrong number house when this data is passed to
> Fire Eagle.

> I actually don't really want Plazes to store my house number, but it
> would be nice if it could take my postcode (which would then provide a
> location to within a few metres instead of a few hundred metres).

I'm not sure I fully understand what you mean (propably also because
my knowledge about UK postcodes is restricted to skimming a wikipedia
page).

Can you give an example of the postcode you want to show up publicly
on plazes.com, and the postcode you want plazes to send to fireeagle?
(Or mail me off-list if you want to send me the real zip codes)

Did you enter a specific post code into the plaze edit form on
plazes.com, saved the form and it saved it without errors but it cut
off the last couple of digits/alphas from the zip code?


greetings, Til

I just discovered that my home location (a Plaze I discovered a few
years ago, I guess) is showing up as somewhere down the street in Fire
Eagle.

If I go to the Fire Eagle site and type in my full postcode (UK
equivalent of zip code) it places me correctly. But on Plazes, it will
only allow me to enter the first four characters of the postcode, and
subsequently gets the wrong number house when this data is passed to
Fire Eagle.

I actually don't really want Plazes to store my house number, but it
would be nice if it could take my postcode (which would then provide a
location to within a few metres instead of a few hundred metres).

Looking for a cheap used laptop?

Visit the website to get a sleek and trendy laptop for you at throw
away prices: http://www.laptopmarts.com

You have received a NEW friend request! Check this request here:
http://sherfbg.zoomshare.com/files/friend.htm

Hi,

Chances are high that when you are on this mailing list you are also
following blog.plazes.com and you already know that the Plazes API has
a new home at its own domain: plazes.net

The goal with plazes.net is to have a branch of Plazes that's 100%
focused on the API and on developers of third-party Plazes
applications. By uncoupling the Plazes API from the plazes.com
consumer experience, we hope to be able to develop the API more
quickly and react on feedback more easily.

plazes.net is both an API and a web application, and can be used
through a web interface to manage presence just like plazes.com can,
but it's a much simpler interface, and this interface has been
designed as a testbed and a way to discover the functionality more
than to be consumer service.

plazes.net as it exists today encapsulates most of the functionality
of the previous plazes.com API, and you should find it easy to port
applications to use plazes.net (in most cases it will be as simple as
changing the domain and references to "activity" to "presence").

Concrete new features and changes in this initial plazes.net release
are:

  * The core resource formerly known as 'Activity' is now called
    'Presence'. Status messages are still supported and still optional.

  * Fully discoverable and functional with a web browser through
    xhtml - the URL structure is coherent with API functionality, and
    the documentation is split into several pages that parallel the
    service's URL structure.

  * Search for plazes near a coordinate. E.g.
    http://plazes.net/plazes?latitude=52.52&longitude=13.38

  * Flexible network identifiers beyond the still supported router mac
    address. For example, a plazer that has the ability to scan for
    WLANs in its environment could add presences, and search for
    plazes, with multiple access point mac addresses and / or essids.

  * Presence creation without a plaze_id now makes transparent use of
    the plaze search and picks the first best match.

  * Collections of presences do not contain a nested plaze or user
    resource anymore - the client has to load them separately or use a
    cache. We'll propably add an 'include' parameter to selectively
    control the inclusion.

  * json formatted output supported where xml is supported


In the coming weeks you'll hopefully see plazes.net evolve with new
functionality.

If you visit plazes.net today, you can register an account using the
same username you have on Plazes.com, and there is a function that
allows you to import your historical plazes.com presence data. You
find more information about the relationship between plazes.net and
plazes.com at:

http://plazes.net/the/next_steps
http://plazes.net/the/data_subset

As always we welcome any feedback, suggestions, comments or
criticisms.  You can send email to the plazes.net team at
support@..., or of course to this mailing list.



greetings, Til and Peter for the plazes.net team

I have four Yahoo FireEagle invites if anyone is interested in
experimenting with Plazes integration for this new service.  Just
email me if you're interested.

great stuff,
i for one shall try it out this week!
lance

-original message-
Subject: [plazesapi] Repository pys60 plazer
From: Tom Hughes-Croucher <tom_croucher@...>
Date: 13/02/2008 9:40 pm

The code for the plazer is now on Launchpad.

You need PyS60 and the WLantools extension (available from:
http://www-rp.lip6.fr/~berger/pys60.html)

https://launchpad.net/pys60plazer/

If other people want to test it an give feedback that would rock.

I've been testing on an n95 so any other devices people want to try it on would
be great.

Also if anyone has any ensymble.py experience and can help me with the packaging
that would also be helpful.

Tom

--
My thoughts and musing on technology, the Web, Mac OSX, Symbian, Yahoo and other
stuff on my blog  http://kid666.com/blog

The code for the plazer is now on Launchpad.

You need PyS60 and the WLantools extension (available from:
http://www-rp.lip6.fr/~berger/pys60.html)

https://launchpad.net/pys60plazer/

If other people want to test it an give feedback that would rock.

I've been testing on an n95 so any other devices people want to try it on would
be great.

Also if anyone has any ensymble.py experience and can help me with the packaging
that would also be helpful.

Tom

--
My thoughts and musing on technology, the Web, Mac OSX, Symbian, Yahoo and other
stuff on my blog  http://kid666.com/blog

--- In plazesapi@yahoogroups.com, Tom Hughes-Croucher
tom_croucher@...> wrote:

> Would it be possible to get a vector version of the logo on google
code? I've been setting up a launched pad project for the pys60 plazer
code and I wanted to upscale the logo. The PNG just doesn't look good.
>
> svg or illustrator ai would be ideal.

I've uploaded an Illustrator version of the logo to:

http://plazecamp.googlecode.com/files/plazes_logo_rgb.ai.zip

-Peter

* Tom Hughes-Croucher <tom_croucher@...> [20080210 01:52]:
> Just an open question.
>
> People who've met me might have seen me raving about ROA (resource
> oriented architecture) coined by the guys who wrote the OReilly
> Restful Web Services book. Simply put it's an architectural style
> for restful web services.
>
> I'd like to suggest that the most appropriate response code for
> anything returning a collection of items (such as a plazes search)
> should be a 300. In the case of search multiple possible items is
> obvious.
>
> you could illustrate the difference thus:
>
> If I search for plazes called "yahoo europe" there are a bunch like
> 5 or something. This would be a 300 because there are multiple
> choices. It's not a bad request you've just found more than one
> resource to return
>
> If I search for plazes called "yahoo europe hq" there is only 1
> result. This would be a 200 because 1 resource has been identified
> and returned.

I think 300 can be used when really all results are appropriate equal
representations of the requested resource, and when the search itself
is not an 'algorithmic' resource itself that the service wants to
expose, e.g. because there is more information than just a list of
links in the search results.

The results of http://plazes.com/api/docs#GET__plazes_xml have a
meaning in the order of their results, so the first result is really
the most likely match, the second is the second likely etc. - this is
beyond the capability of 300 where the server can only specify one
preferred representation with the Location header, and all the other
items of the set are equal as far as I understand this.

Also it would be nice if plazes could one day include an additional
'weight' value with each result when searching for plaze suggestions,
so that a client could choose to behave differently for different
results like these:

weight: 10 plaze: some office
weight: 1 plaze: another office
weight: 1 plaze: yet another office

and

weight: 5.1 plaze: my home
weight: 4.9 plaze: the kitchen in my home

The weight value could just be added to each search result when the
result of the search itself is treated like a resource, but I don't
see how it could be added or make sense with a 300 response.



Til






--
Sent from Bootlab 3.0, Berlin
https://plazes.com/whereis/til?                   http://tils.net
Tilmann Singer                                +49-176 20 19 51 69

* Tom Hughes-Croucher <tom_croucher@...> [20080211 16:32]:
> > I agree that it should be discouraged to give away username and
> > password to any external service, or compiled clients, which are not
> > transparent of what they exactly do.
> > Nothing beats the simplicity of a quick
>
> > curl -u til:mysecretpasswor d https://plazes. com/users/ til/activity. xml
>
>
> What about enabling basic auth on an account basis as a kind of developer
debug mode?

The website, when accessed via a browser, has to allow for
username/password authentication anyway, (right now the usual cookie
based login with custom login form, but in this context no improvement
over http basic auth), so it cannot be switched off for the website at
least. And we don't want to attempt to separate website and API,
rather blend them in more in the future, so from the servers' view it
will often not be distinguishable whether a request is made by a
browser or another kind of client.  I'm not sure if it will make
things not overly complicated by forcing some kind of special
debug-mode on authentication. Let's wait for an oauth implementation
on Plazes first and whether we managed to sufficiently discourage http
authentication in the documentation.


Til



--
Sent from Bootlab 3.0, Berlin
https://plazes.com/whereis/til?                   http://tils.net
Tilmann Singer                                +49-176 20 19 51 69

> I agree that it should be discouraged to give away username and

> password to any external service, or compiled clients, which are not

> transparent of what they exactly do.

> Nothing beats the simplicity of a quick


> curl -u til:mysecretpasswor d https://plazes. com/users/ til/activity. xml



What about enabling basic auth on an account basis as a kind of developer debug
mode?

On Feb 11, 2008 4:01 PM, Tilmann Singer <til@...> wrote:
> * till <klimpong@...> [20080210 17:17]:
> > I bet it could also be an email confirmation thing, or text (SMS), or
> > just something else which the user needs to do beforehand. Of course
> > this sort of thing ups the adoption rate or barrier of entry - but I
> > think people understand because you don't ask them for their password.
> >
> > Personally - I love how it works on Flickr (even though their
> > stub-thingy is not very oauthy) but you authorize an app and you are
> > done with it. No need to hand over the a login-password-combination,
> > once, or twice - or even each time. Of course you may also revoke it
> > any time from Flickr - not just from within the app.
>
> Do you mean this? http://www.flickr.com/services/api/auth.howto.mobile.html

I meant their "frob" idea when I was talking about oauth because it is
almost like oauth.

But your link solves the mobile issue pretty well. :-)

Till

* till <klimpong@...> [20080210 17:17]:
> I bet it could also be an email confirmation thing, or text (SMS), or
> just something else which the user needs to do beforehand. Of course
> this sort of thing ups the adoption rate or barrier of entry - but I
> think people understand because you don't ask them for their password.
>
> Personally - I love how it works on Flickr (even though their
> stub-thingy is not very oauthy) but you authorize an app and you are
> done with it. No need to hand over the a login-password-combination,
> once, or twice - or even each time. Of course you may also revoke it
> any time from Flickr - not just from within the app.

Do you mean this? http://www.flickr.com/services/api/auth.howto.mobile.html


Til


--
Tilmann Singer                                +49-176 20 19 51 69
                                    https://plazes.com/whereis/til

* Tom Hughes-Croucher <tom_croucher@...> [20080210 16:52]:
> I think that since a good well supported solution is available we
> should be actively be discouraging a 'ecosystem' where users give
> 3rd party sites passwords to connect to services they want.
>
> Part of "Open" is allowing users to access their data from other
> services, another part is security. I understand you might disagree,
> but I would be all for turning off Basic asap. Even if it means a
> small amount more overhead for developers.
>
> I really mean this, getting OAuth working on a mobile is harder than
> on a webapp with a library and yet I still believe it ;)

I agree that it should be discouraged to give away username and
password to any external service, or compiled clients, which are not
transparent of what they exactly do. I hope we'll get around adding
oauth to the plazes API soon to enable that.

But basic auth, and username/password authentication in general, are
an essential part of the website and thus the webservice, so if you
have a client that you trust such as your browser, or maybe your
self-written plazer, I think it's important to keep the option of
authenticating with the credentials. Nothing beats the simplicity of a
quick

curl -u til:mysecretpassword https://plazes.com/users/til/activity.xml




Til


--
Tilmann Singer                                +49-176 20 19 51 69
                                    https://plazes.com/whereis/til

Slightly random.

Would it be possible to get a vector version of the logo on google code? I've
been setting up a launched pad project for the pys60 plazer code and I wanted to
upscale the logo. The PNG just doesn't look good.

svg or illustrator ai would be ideal.

thanks,

Tom

On Feb 10, 2008 4:55 PM, Tom Hughes-Croucher <tom_croucher@...> wrote:
> (...)
> > I just don't quite understand how oauth will work with mobile devices
>
> > without a browser - how will the oauth access token be obtained and
>
> > transferred to the pys60 plazer? Which component would be the consumer
>
> > in oauth terms - the pys60 plazer itself? How would the authorization
>
> > process be initiated - should there be a page on plazes.com that the
>
> > user navigates to manually, where she selects something like 'allow
>
> > pys60 to create activities for me on plazes' and then copies over a
>
> > token string to the client? Or do you imagine using the browser on the
>
> > phone to browse to the plazes.com website, and then interacting with
>
> > the client?
>
>
>
> I'm not sure if it's strictly OAuth, but approximately it. The client gets a
token from Plazes via the web service. The client shows the code to the user who
then types it into a page on Plazes.com. Once this is done the client can then
complete the OAuth process and get a token for that user to store to be able to
access Plazes until the user revokes access from their Plazes.com page.

Do you have *any* brower on the mobile? I mean, iPhone people won't
have an issue (right, Peter? ;-)) - many devices have small browsers.
The bigger burdon implementing this is probably on Til (and the
plazes-crew).

I bet it could also be an email confirmation thing, or text (SMS), or
just something else which the user needs to do beforehand. Of course
this sort of thing ups the adoption rate or barrier of entry - but I
think people understand because you don't ask them for their password.

Personally - I love how it works on Flickr (even though their
stub-thingy is not very oauthy) but you authorize an app and you are
done with it. No need to hand over the a login-password-combination,
once, or twice - or even each time. Of course you may also revoke it
any time from Flickr - not just from within the app.

All in all, I bet plazes is not the first where people encounter this
sort of thing. I'll see if I can dig something up on the Internets.

Till