On Sab, 11 de Junio de 2005, 21:05, Glen Ezkovich dijo: > > On Jun 11, 2005, at 7:53 PM, Antonio Gallardo wrote: > >> On Sab, 11 de Junio de 2005, 10:34, Carsten Ziegeler dijo: >> >>> Glen Ezkovich wrote: >>> >>>> >>>> The fix appears easy, but is something broken? Has someone expressed >>>> the desire to use two languages in a single sitemap or is this just >>>> an instance of feature creep? >>>> >>> I tend to agree, so I think we should for now just forbid to write >>> different map:flow sections in a single sitemap (by different I mean >>> that they use a different interpreter). If someone wants to use more >>> than one language we can add that easily. >>> >> >> This made me think about the future: >> >> 1-Exists or will exists the need to migrate JSflow to javaFlow (legal, >> convenience, user desire or whatever)? > > Easing migration would be more of concern if my answer to #2 were > yes. There are workarounds that I think would be more appropriate > such as separate sitemaps for migrating to JavaFlow.
Well, there is a fact we need still need to solve around rhino. On the other side, I hear there are some troubles using Bcel inside JVM-code for java 1.5 (I never tried, perhaps it was only FUD). >> 2-Should we want to encourage people to write Javaflow instead of >> JSFlow? > > No. While I plan on using Javaflow going forward, JSFlow makes flow > available to Javascript programers (web masters). > >> 3-Need to be a web glue for flow code too? > > Don't know yet. What is the use case? We know JSFlow exists longer than JavaFlow. A usecase can be people wanting to use already tested JSFlow while writting newer code using JavaFlow. > I just think its prudent to wait until there is a real need before we > add a feature that may introduce complexities. I agree. I just wanted to give some ideas of why this should be good. I don't feel the need of support both flow scripts right now and dunno if in the future I will need both on the same sitemap. Perhaps the answer is never. In anycase if this is too much complicated to implement or a waste of time (including runtime), I believe we will find better way to migrate if needed. Best Regards, Antonio Gallardo
