Closed tuttinator closed 10 years ago
fwiw, I don't feel awfully strong about .io vs a normal github.io page - any thoughts @colinta @markrickert
@mattetti are you the admin of the domain?
Hey Clay, I am not @jamesotron is
On Mon, Jun 2, 2014 at 9:17 AM, Clay Allsopp notifications@github.com wrote:
fwiw, I don't feel awfully strong about .io vs a normal github.io page - any thoughts @colinta https://github.com/colinta @markrickert https://github.com/markrickert
@mattetti https://github.com/mattetti are you the admin of the domain?
— Reply to this email directly or view it on GitHub https://github.com/rubymotion/BubbleWrap/issues/384#issuecomment-44858127 .
Same here, github.io is good w/ me :smiley:
I think for SEO and discoverability reasons (also all the links from blog posts) would be better to renew the domain
That's true - @jamesotron I'd be happy to renew the domain another year, if you can get in touch via email (clay at usepropeller dot com)
but I think I'd like to make it 302 to github.io - having an external domain is a dependency I'd rather avoid, if possible
Agreed on the external dependency... at least let it 302
to github.io for a year to get everyone's indexes updated so that google isn't pointing people to bubblewrap.io
Speaking of which, I'll probably port some of BW to Swift. Is this something you guys are OK with putting in the same repo or would you prefer it in its own repo? (Obviously having the info on the same site would be great) On Jun 3, 2014 12:35 PM, "Mark Rickert" notifications@github.com wrote:
Agreed on the external dependency... at least let it 302 to github.io for a year to get everyone's indexes updated so that google isn't pointing people to bubblewrap.io
— Reply to this email directly or view it on GitHub https://github.com/rubymotion/BubbleWrap/issues/384#issuecomment-44988520 .
hm, that sounds like it should be a separate project. moving forward, BubbleWrap will focus on appropriate cross-platform abstraction with RubyMotion, don't think Swift fits in with that
but yeah, no problem if you want to re-use the APIs etc
Given that I am the original author of this project, I will keep the original name but I agree that starting a new repo makes sense. On Jun 3, 2014 1:39 PM, "Clay Allsopp" notifications@github.com wrote:
hm, that sounds like it should be a separate project. moving forward, BubbleWrap will focus on appropriate cross-platform abstraction with RubyMotion, don't think Swift fits in with that
but yeah, no problem if you want to re-use the APIs etc
— Reply to this email directly or view it on GitHub https://github.com/rubymotion/BubbleWrap/issues/384#issuecomment-44996442 .
With all due respect, that sounds like a bad idea. Google results for "bubblewrap ios" are dominated by RubyMotion results - a name collision will only confuse users of your library and users of BubbleWrap.
Yes, but you gave this project to the community - what is the point in keeping the name, anyway?
On Jun 3, 2014, at 12:48 PM, Matt Aimonetti notifications@github.com wrote:
Given that I am the original author of this project, I will keep the original name but I agree that starting a new repo makes sense. On Jun 3, 2014 1:39 PM, "Clay Allsopp" notifications@github.com wrote:
hm, that sounds like it should be a separate project. moving forward, BubbleWrap will focus on appropriate cross-platform abstraction with RubyMotion, don't think Swift fits in with that
but yeah, no problem if you want to re-use the APIs etc
— Reply to this email directly or view it on GitHub https://github.com/rubymotion/BubbleWrap/issues/384#issuecomment-44996442 .
— Reply to this email directly or view it on GitHub.
I think the name encapsulates a concept and that's why I thought it made sense to have 1 page and direct people towards the implementation they want.
Same concept, similar or identical APIs but different languages. On Jun 3, 2014 3:32 PM, "Colin T.A. Gray" notifications@github.com wrote:
Yes, but you gave this project to the community - what is the point in keeping the name, anyway?
On Jun 3, 2014, at 12:48 PM, Matt Aimonetti notifications@github.com wrote:
Given that I am the original author of this project, I will keep the original name but I agree that starting a new repo makes sense. On Jun 3, 2014 1:39 PM, "Clay Allsopp" notifications@github.com wrote:
hm, that sounds like it should be a separate project. moving forward, BubbleWrap will focus on appropriate cross-platform abstraction with RubyMotion, don't think Swift fits in with that
but yeah, no problem if you want to re-use the APIs etc
— Reply to this email directly or view it on GitHub < https://github.com/rubymotion/BubbleWrap/issues/384#issuecomment-44996442>
.
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHub https://github.com/rubymotion/BubbleWrap/issues/384#issuecomment-45009798 .
Call it SwiftWrap. ;)
I think that people coming from Swift and finding a very popular RubyMotion gem, that is reimplemented in Swift, and then never used by RubyMotion developers, well they would be just as confused as we are, and ultimately less likely to use it.
I'm not sure anyone here can convince you that this sounds like a confusing idea, but please sleep on it.
Will do On Jun 3, 2014 3:58 PM, "Colin T.A. Gray" notifications@github.com wrote:
I think that people coming from Swift and finding a very popular RubyMotion gem, that is reimplemented in Swift, and then never used by RubyMotion developers, well they would be just as confused as we are, and ultimately less likely to use it.
I'm not sure anyone here can convince you that this sounds like a confusing idea, but please sleep on it.
— Reply to this email directly or view it on GitHub https://github.com/rubymotion/BubbleWrap/issues/384#issuecomment-45012662 .
sweet!
any ideas for rubymotion.github.io?
On Jun 18, 2014, at 2:50 PM, Clay Allsopp notifications@github.com wrote:
Now at http://rubymotion.github.io/BubbleWrap
— Reply to this email directly or view it on GitHub.
Links in the README and the repo description point to bubblewrap.io, but this domain no longer seems to resolve