Btw, I should have split one paragraph: > 2. Hypothetically, I spend more time on my project and it turns out great and > everyone wants to use it :P. Would, or should, it live at Apache? I would > definitely be willing to donate it.
That would be very cool, and yes (as stated in the paragraph above) I think it would fit really well. All we would need for such a bigger contribution is to file an iCLA [1]. txs and LieGrue, strub [1] http://www.apache.org/licenses/icla.txt ----- Original Message ----- > From: Mark Struberg <[email protected]> > To: "[email protected]" <[email protected]> > Cc: > Sent: Saturday, June 16, 2012 12:05 PM > Subject: Re: Introduction and another viewer > > Hi Adam! > > Really good questions and sorry that you tapped into the legal mine field > that > early. I hope this doesn't distract you too much from your intended hacking > ;) > > > Just to explain the rational behind this a bit further: > > _every_ OSS developer must be really carefully when it comes to legal aspects > nowadays (Goog vs Orcl anyone?) > This is not folks at ASF being weirdos but we only like to protect our > contributors (thus you and others) by making them aware. That's one of the > reasons for our VOTEs on releases, ip-clearance [1] etc. We even maintain an > own > legal-discuss list where a few pro-bono lawyers, attorneys and even law > professors also show up and help us resolving more difficult legal questions > (big thanks btw!). > > > For the basics: an algorithm cannot be patented and also not being > 'protected' via Intellectual Property rights (IP). But copying a bigger > source 1:1 is problematic as it can lead to breaching IP. > Thus taking the idea of this single loop of 4 lines and rewriting them in > your > own code is absolutely no problem. Simple copying code is never a good idea > though - be it for only changing code style or reviewing the code that way. > > > *skipping the technical ISIS questions, Dan please take over ;) * > > >> 1. Is this the correct forum to discuss these issues? I will definitely be > using >> Isis to generate my Restful Objects with the json-viewer but I don't > want to >> hijack the mailing list for these kinds of things unless it can benefit the > Isis >> community. > > It's perfectly fine to discuss it here on the list and even develop the > viewer here. If this can be done in a 'portable', way we should take > care to keep that part abstract and independent. But it's always a good idea > to have at least a known server part it interacts well with. If it proved > stable > and universal, we can still split it out into an own project later on. Once > one > becomes an ASF committer on one project it's really easy to 'extend' > into other project communities as well ;) > > >> 2. Hypothetically, I spend more time on my project and it turns out great > and >> everyone wants to use it :P. Would, or should, it live at Apache? I would >> definitely be willing to donate it. But how would it be packaged? It's > own >> viewer? That doesn't make sense because it needs the json-viewer to > operate. >> A Maven war overlay of the json-viewer or webpp artifacts? Maybe. What if > the >> .NET guys want it? I'm completely unfamiliar with NuGet and how it > manages >> packages but I'm guessing it doesn't interoperate with Maven. > > No clue about that right now. We would need to take a deep look at the > details. > But I'm sure we can solve this! > >> I develop the code on GitHub under MIT license. >> Johan doesn't respond and his code is abandoned. >> I like his work so I merge our codebases giving him >> attribution. The code is now "IP unclean. > > There is a very good summary and a license compat matrix here: > http://www.apache.org/legal/3party.html > > MIT is perfectly fine to include in our work. Of course keep the author > attribution. > I'm not sure how big the parts are you like to 'copy' from him 1:1 > or if you/we more or less create own 'derivative' work by taking his > code as base for _some_ features but changing/adopting/extending it ourselfs. > This is really often the case if you take code from someone else. > We also might try to reach out as PMC, telling him what we like to do and if > he > is cool with that. > The worst thing which could happen is imo that we need to rewrite those parts > we > didn't yet touch. > > > LieGrue, > strub > > [1] http://incubator.apache.org/ip-clearance/index.html > whoooops, I think we are still missing here ^^ > > > > ----- Original Message ----- >> From: Adam Howard <[email protected]> >> To: [email protected] >> Cc: >> Sent: Saturday, June 16, 2012 5:06 AM >> Subject: Re: Introduction and another viewer >> >> I'm including responses to both Mark and Dan here. I don't know if > that >> meets >> list etiquette. Also should I be including full message history in every > reply? >> >> >> On Fri, Jun 15, 2012 at 12:16 PM, Mark Struberg <[email protected]> > wrote: >>> >>> The point is that here at ASF we only take code if someone explicitly >>> gives it to us. >>> Of course not if those are only a few lines of code or a pretty > straight >>> forward basic task without much own work. But it's more complex > and >>> originary work then we just don't take it. >> >> So for example, I wanted a unique id for every window and field in my ui. I >> googled for javascript guid and found a 4 line function that generates >> something "kind of like" a guid. Definitely random enough for my > use. >> Is that a >> case where I would need to track down the author and ask if they will > donate the >> code to ASF. I can think of many levels of scenarios. Is there a document >> outlining this? I don't want to "poison" my project this > early :) >> >> >> On Fri, Jun 15, 2012 at 8:59 AM, Dan Haywood >> <[email protected]> >> wrote: >> >>>> One of those features, though, you mentioned as a possible > negative of >> the >>>> DnD viewer was maintaining a client-side cache of objects... >>> >>> Indeed. Those caches can get out of date; at least: they do on the > Irish >>> system. >>> >>> The main workaround there is that, when the user searches for a > Customer, >>> then the client invalidates the client-side cache. It works well > enough >>> because the Customer is the usual start point for most business > processing. >>> But it's not generic solution, ie is a hack. >> >> The cache that Johan is using seems a little different. When a domain > object is >> returned from Isis, the graph is walked and more requests are made for >> properties, collections and descriptions. These all feed into a local >> representation of the state of the object. The window then displays the > object >> as it exists in the cache. On subsequent requests for the object, it is > ALWAYS >> refreshed from the server including all of its relations. So the cache is > really >> just used to ensure that all current views are in sync with each other. So > you >> change the name of a project and it's title is updated in the project > list >> view >> because they are both pointing at the same javascript object. >> >>> Also (and this is even more of a dirty secret), the validation methods >>> (hidden, disabled, validate) run client-side. Strictly speaking, they >>> should run server-side which would force the latest version of the > object >>> to be grabbed. >> >> You mention the object's version. Is there an optimistic locking > property >> exposed in RO? I searched the 1.0.0 spec and couldn't find one. >> >>> This second point isn't an issue with an RO-based client, because >>> validation must trigger a call to the REST API... there is no Java > code >>> client-side. Of course, with REST we can using HTTP caching to stop > the >>> server being flooded with calls. >> >> The object traversal definitely floods the server. What would the > cache-control >> be on an entity? Surely if we're asking we would want the latest > version? >> Related to the optimistic locking property above would we say "I want >> object >> OID:10. I currently have v123" and the server could determine that > v123 was >> the >> latest and send us a 304 (or do we keep track of when we requested the > object >> and send that as If-modified-since?) Would it be different for value > objects? >> And descriptions? >> >>>> The next step I suppose would be to tie in either the WebSockets > or >>>> EventSource API... >>> >>> Not necessarily... it's hard to say. I guess we're all going > to >> learn >>> where websockets (and related technologies) work well and where they >> don't >>> as HTML5 becomes commonplace. >>> >>> I do think it's worth taking this work forward and seeing what > happens. >>> But ultimately it will require server-side changes to fully > support... It >>> might end up being quite simple to implement, hard to say. >>> >>> It also occurs to me that a full WebSockets impl would mean that the > UI >>> would change dynamically in front of a "user's eyes". >> Although that sounds >>> cool, I could also see that it might be disconcerting in some > scenarios. >>> (You wouldn't want that to happen to a Java source file you were >> editing, >>> for example). >> >> There would be server-side changes and I don't know enough about how a >> property >> gets changed on an object to guess at the implementation. The two use cases > I >> can see for this are streaming data and update announcements. Streaming > data >> could be like a stock ticker or a continually updating chart. I've > played >> with >> that before. The update announcements would broadcast that an object has > changed >> server-side. It could include the full object or just the object id. The > viewer >> could then choose to update the object in place or set a stale flag. >> >> It could be strange to see my Project view change in front of me > (especially >> while I'm editing!) but there are cases where this could be very > useful: >> >> * Shipping: Live map of where your package is. >> * The energy trading example from the first Naked Objects book. >> * Collaborative drawing: Not really a business system but often used to > describe >> how rich we should strive to make our interfaces >> >> In the end, WebSockets is just a more server-friendly way to do what we > have >> been doing with polling. >> >> ========= >> Disclaimer: I love Apache. I wouldn't be able to do my job without it. > All >> of the questions below are purely hypothetical and for clarification > purposes. >> >> One question came up while writing all this and thinking about what Mark > said. >> What we are really talking about here is a Restful Objects viewer and not > an >> Isis viewer. At least not in the same sense as the HTML, Scimpi, or Wicket >> viewers. That being the case, the jqMobile interface, Johan's project, > my >> project, etc. are not Isis-specific (unless they use something in > extensions.) >> Two questions: >> >> 1. Is this the correct forum to discuss these issues? I will definitely be > using >> Isis to generate my Restful Objects with the json-viewer but I don't > want to >> hijack the mailing list for these kinds of things unless it can benefit the > Isis >> community. >> >> 2. Hypothetically, I spend more time on my project and it turns out great > and >> everyone wants to use it :P. Would, or should, it live at Apache? I would >> definitely be willing to donate it. But how would it be packaged? It's > own >> viewer? That doesn't make sense because it needs the json-viewer to > operate. >> A Maven war overlay of the json-viewer or webpp artifacts? Maybe. What if > the >> .NET guys want it? I'm completely unfamiliar with NuGet and how it > manages >> packages but I'm guessing it doesn't interoperate with Maven. >> >> One scenario… >> I develop the code on GitHub under MIT license. Johan doesn't respond > and >> his >> code is abandoned. I like his work so I merge our codebases giving him >> attribution. The code is now "IP unclean." If I can get it > published >> to maven >> central I can create a maven war overlay of the Isis json-viewer. Isis > users >> can include this in their root project but it can't be a part of the >> quickstart >> archetype because of the IP issue. (Is that similar to the fate of the > Hibernate >> backend?) The project is RestfulObjects focused so it could also be shared > with >> the .NET community. I realize I am getting way ahead of myself but like I > said >> at the beginning of this email, I don't want to "poison" the >> project early. >> >> I worry alot about the tone of these messages. I can see how the above > might >> sound combative. >> >> "The computer can't tell you the emotional story. >> It can give you the exact mathematical design, >> but what's missing is the eyebrows." >> -- Frank Zappa >> >> >> Very much enjoying the discussion. >> -- >> Adam Howard >> >> >> On Fri, Jun 15, 2012 at 8:59 AM, Dan Haywood >> <[email protected]> wrote: >>> On 15 June 2012 04:06, Adam Howard <[email protected]> > wrote: >>> >>> I tried it out [Johan's client] ... >>>> He already has many of the features I wanted to add to my little >> project. >>>> ... >>>> >>>> One of those features, though, you mentioned as a possible > negative of >> the >>>> DnD viewer was maintaining a client-side cache of objects. Johan > uses >> this >>>> so that the views can be direct projections of the local model. > You >> change >>>> a field in one view and all others views automatically update. >>> >>> >>> Indeed. Those caches can get out of date; at least: they do on the > Irish >>> system. >>> >>> The main workaround there is that, when the user searches for a > Customer, >>> then the client invalidates the client-side cache. It works well > enough >>> because the Customer is the usual start point for most business > processing. >>> But it's not generic solution, ie is a hack. >>> >>> Also (and this is even more of a dirty secret), the validation methods >>> (hidden, disabled, validate) run client-side. Strictly speaking, they >>> should run server-side which would force the latest version of the > object >>> to be grabbed. >>> >>> This second point isn't an issue with an RO-based client, because >>> validation must trigger a call to the REST API... there is no Java > code >>> client-side. Of course, with REST we can using HTTP caching to stop > the >>> server being flooded with calls. >>> >>> >>> >>> >>>> The next >>>> step I suppose would be to tie in either the WebSockets or > EventSource >> API >>>> to allow the server to broadcast object change events back to all >> connected >>>> viewers. Would you advise against this sort of approach? >>> >>> >>> Not necessarily... it's hard to say. I guess we're all going > to >> learn >>> where websockets (and related technologies) work well and where they >> don't >>> as HTML5 becomes commonplace. >>> >>> I do think it's worth taking this work forward and seeing what > happens. >>> But ultimately it will require server-side changes to fully > support... It >>> might end up being quite simple to implement, hard to say. >>> >>> It also occurs to me that a full WebSockets impl would mean that the > UI >>> would change dynamically in front of a "user's eyes". >> Although that sounds >>> cool, I could also see that it might be disconcerting in some > scenarios. >>> (You wouldn't want that to happen to a Java source file you were >> editing, >>> for example). >>> >>> >>> >>> >>>> Or is the >>>> client-side cache you mention more an artifact of the remoting >> protocol? >>>> >>> >>> The bespoke remoting that we had (and have now thrown away) certainly >>> didn't help matters. But it was also complicated by the fact that > OIDs >>> (the serializable object identifier by which we identify every object, > eg >>> "customer|123") used to be mutable. This was because an > object >> would be >>> transient client-side, then get persisted (ie: users hits the >> "save" >>> button), then the object would be sent over the wire, persisted, and > its >>> OID would change. Figuring all this stuff out was complex. >>> >>> OIDs are now immutable, which basically means that we don't really > >> support >>> transient objects anymore. I can think of patterns that would allow > us to >>> simulate this, though. >>> >>> >>> >>> >>>> >>>> On Heroku, I just signed up for the account to post this demo. It >> seemed >>>> like the easiest and cheapest (free) way to post a simple java > webapp. >>>> Especially since I didn't require an RDBMS. My 24 hours of >> experience have >>>> been fine. >>>> >>> >>> OK, looking into it. I'm also looking at CloudBees and OpenShift, > cos >> I >>> want a (non-Apache) CI server for this new project that is kicking > off. >>> >>> >>> >>> >>>> >>>> On the iPad, I thought this would be cool too and then started to > think >>>> about how dragging and right-clicking doesn't work. Then I > found >> jQuery UI >>>> Touch Punch [1] which maps the jQuery UI events to touch events: > click >>>> becomes tap, right-click becomes tap & hold, and they've > made >> dragging and >>>> dropping work as well. I'll definitely have to try it out. >>>> >>> >>> It's great how many of these UI frameworks are. Hopefully the > REST API >>> will allow for all sorts of interesting user interfaces going forward. >>> >>> Cheers >>> Dan >>> >>> >>> >>>> >>>> -- >>>> Adam Howard >>>> >>>> [1] http://touchpunch.furf.com/ >>>> >>>> On Thu, Jun 14, 2012 at 10:12 AM, Dan Haywood >>>> <[email protected]>wrote: >>>> >>>> > Hi Adam, >>>> > Welcome to Isis, and thanks very much for your interest and > the >> good work >>>> > you've already done so far! >>>> > >>>> > Since you've made a number of points, I've commented > on >> them inline.... >>>> > >>>> > >>>> > On Thursday, 14 June 2012, Adam Howard wrote: >>>> > >>>> > > >>>> > > I started reading Dan's book last fall and made it > part >> way through the >>>> > > carserv example app using Isis 0.1.2-incubating. I used > the >> DnD viewer >>>> > > almost exclusively, enjoying how tangible the objects > became >> using the >>>> > > multi-window interface. >>>> > > >>>> > >>>> > >>>> > >>>> > > >>>> > > About a month ago I came back to the book and decided to > >> start writing >>>> my >>>> > > own little app alongside carserv. I grabbed the latest > Isis >> quickstart >>>> > > archetype (0.2.0-incubating) and started coding. >> Surprisingly, I saw >>>> that >>>> > > the DnD viewer was no longer included as standard in the > >> archetype. I >>>> > used >>>> > > the HTML viewer for about a week but it just didn't > feel >> the same. With >>>> > the >>>> > > DnD viewer I could look at my object representations and > it >> would help >>>> > > drive my modeling. "Oh, I need a relationship here > so I >> can drop this >>>> > > object on that one." >>>> > > >>>> > >>>> > Like you, I also have a soft spot for the DnD viewer, and Rob > does >> too of >>>> > course because it's his baby. It's also the viewer >> that's used on the >>>> big >>>> > system in Ireland, used by 2,500+ people on a day-to-day > basis. >>>> > >>>> > On the other hand, the DnD viewer, let's say, not the >> prettiest of UIs. >>>> > (For myself at least) I'm pretty sure lots of people > have >> seen it and >>>> got >>>> > turned off by Isis / the naked objects pattern.... >>>> > >>>> > As you've probably realized, the DnD viewer code itself > has >> not been >>>> > deleted. However, we removed it from the archetype because: >>>> > * we wanted to try to include only the stuff that was >> "complete", and in >>>> > its current incarnation a few new features are only >> semi-implemented >>>> > * its status was becoming less clear with the move to remove > the >> remoting >>>> > stuff >>>> > * to figure out what it's positioning should be within > the >> context of the >>>> > other viewers. >>>> > >>>> > Where I think we are now is that we see the DnD viewer as > being >>>> > resurrected, but positioned solely as a design tool for >> developers. >>>> > >>>> > At some point Rob needs to do some tidy up work to remove the >>>> > semi-implemented features and get it back to where it was >> (ideally: I'd >>>> > like it to look like NOF 3.0.3, with the collections on the > left). >> As >>>> and >>>> > when that's done, I'll add it back into the > archetype. >>>> > >>>> > In the meantime, you can of course create a Maven module and >> reference >>>> the >>>> > viewer; the module generated from the 0.1.2-incubating > archetype >> will >>>> > probably work just fine (save change the version of Isis >> referenced, >>>> > obviously). >>>> > >>>> > >>>> > >>>> > >>>> > > >>>> > > This got me wondering. Could a browser-based > multi-window >> interface be >>>> > > built on top of the JSON viewer and a javascript ui > library? >> I looked >>>> at >>>> > > all the contenders (YUI, jQuery, MooTools, Backbone, > ExtJS) >> and finally >>>> > > settled on jQuery after seeing this blog post [1] and > looking >> at the >>>> > > jqMobile example. >>>> > > >>>> > >>>> > Indeed. And in fact a chap called Johan Andries had the same > idea >> and >>>> > spent some time putting together an early JS application > against >> the >>>> > Restful interface using JQueryUI and Backbone. He's also > >> shared his >>>> code, >>>> > at [5]. >>>> > >>>> > >>>> > >>>> > >>>> > > >>>> > > I've been playing with it for the past couple weeks > and >> I'm at the >>>> point >>>> > > where I wanted to know if this is something the > community is >> interested >>>> > in. >>>> > > I know it's ANOTHER viewer and I'm making no > claims >> that it's ready (or >>>> > > will ever be ready) for anyone else to use. I'm > really >> asking if the >>>> > ideas >>>> > > embodied in the DnD viewer are still desired? >>>> > >>>> > >>>> > Yes, I think they are. In fact, Johan's viewer also uses > the >> DnD as its >>>> > metaphor. I had a quick play with your app [4] (though not > for >> long) >>>> and I >>>> > think that Johan has gotten a little further with his > framework >> than you. >>>> > That said, he doesn't seem to have done any work on it > since >> Nov last. >>>> > >>>> > So, one option you might want to explore is to contact Johan > and >> either >>>> > join his project, or fork it and take it from there. >>>> > >>>> > For myself, I was thinking that a GUI based on ExtJS might do > well >> as a >>>> > sovereign style app... but I can't see myself starting on > that >> this year >>>> > (2012). >>>> > >>>> > >>>> > >>>> > > The most important to me >>>> > > being multiple objects on a virtual desktop that you can > >> visually >>>> layout >>>> > to >>>> > > increase understanding. >>>> > > >>>> > >>>> > Agreed. Also, with toolkits such as SenchaTouch, I think > there >> are >>>> > opportunities for very interactive UIs that can be deployed > on >> iPADs and >>>> > the like. >>>> > >>>> > >>>> > >>>> > >>>> > > >>>> > > All of the latest developments I've seen, both in > Isis >> and >>>> > NakedObject.NET, >>>> > > have centered on single-object view web layouts. Was it >> discovered that >>>> > the >>>> > > desktop metaphor viewers were lacking for some users? >>>> > >>>> > >>>> > The next generation of the Irish government project is indeed > >> moving to >>>> > Naked Objects MVC. It's too early to say how that will > pan >> out. >>>> > >>>> > However, the issue with the DnD viewer is mostly its > architecture: >> the >>>> > client/server remoting protocol, and having to maintain >> client-side cache >>>> > of objects and managing transient/persistent objects and lazy > >> loading >>>> over >>>> > the wire. The Irish app which runs under this architecture > does >> work, >>>> but >>>> > the sordid little secret is that there are a number of hacks > under >> the >>>> > covers to get it to do so. >>>> > >>>> > But this is why the Restful interface (per the json-viewer) > is so >>>> > important, I think: it will enable different types of viewers > with >>>> whatever >>>> > UI paradigm fits, but on a solid, scalable, back-end > architecture >> . >>>> > >>>> > So... I would say, go for it and build a DnD (or whatever) > viewer, >> using >>>> > the restful API. There's no reason not to. >>>> > >>>> > >>>> > >>>> > > The new web viewers >>>> > > are great but they don't give me the same sense of >> exploration as the >>>> > > original GUI. Maybe that exploration isn't needed > after >> the model >>>> > > solidifies and the app is being used. >>>> > > >>>> > > Anyway, sorry for rambling. >>>> > >>>> > >>>> > Not at all... very interested to hear your thoughts. >>>> > >>>> > >>>> > >>>> > > I tried something new and posted my little app >>>> > > on Heroku. If I understand the service right you can > access >> the JSON >>>> > viewer >>>> > > [2], the HTML viewer [3] and my "windowed" > viewer >> [4] at the urls >>>> below. >>>> > It >>>> > > might take a few seconds to spool up. Credentials are >> sven/pass. Tested >>>> > in >>>> > > Chrome, FF, and Safari. >>>> > > >>>> > >>>> > Heroku: that's on my todo list to look into. I might > pick >> your brains. >>>> > >>>> > >>>> > >>>> > > >>>> > > Again it's nowhere near complete but you can execute > >> actions, view >>>> > objects >>>> > > and collections, create objects and modify properties >> (mostly.) >>>> > > >>>> > > Thanks for creating a wonderful framework to build on. >>>> > > >>>> > >>>> > Thanks for the kind words, looking forward to continuing the >>>> conversation! >>>> > >>>> > Cheers >>>> > Dan >>>> > >>>> > >>>> > >>>> > > -- >>>> > > Adam Howard >>>> > > >>>> > > [1] >>>> > > >>>> > > >>>> > >>>> >> > http://net.tutsplus.com/tutorials/javascript-ajax/creating-a-windows-like-interface-with-jquery-ui/ >>>> > > [2] http://simple-dusk-6870.herokuapp.com >>>> > > [3] http://simple-dusk-6870.herokuapp.com/htmlviewer >>>> > > [4] http://simple-dusk-6870.herokuapp.com/services.html >>>> > >>>> > >>>> > [5] http://code.google.com/p/restfulobjects-js/ >>>> > >>>> >> >
